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METHOD AND APFAKATOS FOR CONDUCTING A 
TRANSACTION IN A STATELESS WEB mvmONMENT 

5 FIELD OF THE INVENTION . 

This i«v«»tioii lelates to proc«!Ssing transactions in networked computer systems, and 
more speciftcalJy to processing muMpie-reqtiest traaisactitMis m a stately web environment, 

10 BACKGROUND OF THE INVENHON 

The World Wide Web includes a jietwork of serven; on the Irstemet, each of which is 
associated with one or more HTML (ilj'perJext Markup Language) pages. Tiie HTML pages 
associated with a server provide inforaiaiion and hypertext links to otiier docaments on tJwt 

1 5 and (usually) other servers. Servers cojroiiiinjcate witli clients by using the Hypertext Traiisfer 
Protocol 0~ITTP). The s^ers Jisten for requests from citeots for their HTML pages, and are 
therefore often referred to as 'listeners". 

Users of the World Wide Web use a client prograitJ, referred to as a browser, to 
request, decode and display information from listeners. When tiie user of a browser selects a 

20 link on an HTML page, the browser that is displaying the page a requ«sst over the 

Internet to the listener associated with the Universal Resource Locatw (URL) specified in the 
link. In response to the request, &t& listener transmits the requested information to the browser 
that issued the reqttest. Itse browser receives the informa^on, presents iht received 
information to the user, Kid awaits the next user request, 

25 Traditionally, the information stored on listeners is in the form of static HTML pages. 

Static HTML pages are created and stored at the listesier prior to a request from a weh 
browser. In response to a request, a static HTML page is merely read ftom storage and 
firansr^itted to the requesting browser. Curraotly, there is a trend to develop listeners that 
respond to browsiar requests by performing dynamic operations. For example, a listener may 

30 respond to a request by issuing a query to & database, dynamically constnjcting a web page 
containing the results of the query, and transmitting the dynatnically constructed HTML page 
to the requesting browser. To perform dynamic operations, the fonctionality of the listener 



5/10/07, EAST Version: 2.1.0.14 



PCT/US98/2311I 



- 2- 

m«st be enhanced or augmented. Various approaches have been devetoped for extending 
listeners to ^ppoit dynamic opsmttens. 

One of the major characteristics of the web is that it provides a stateless environment 
That is, HTTP commuuicates iafonnation on a messag©-by-m6s$age basis without any 

5 mechanism for designating relationships between messages. This means that a process 

servicing a current request cannot detennJae whether the mtxmt request came ftom the same 
etient as a previous request In addition, the servicing process cannot determine how or if the 
current request relates to a previous request 

A disadvantjtge with using a stateless environment ss that it is difficult to process 

10 muUipk-rsquBst transactions. A m»ltipie»request transaction ss a set of operations that (i ) are 
Specified in more ihm one request, and (2) must be perfonned as an atomic unit of work. For 
example, a multiple-request transaction could consist of ihree separate operations, such as 
buying stock item A, selling stock item B and updating the inventory to refiect the number of 
stock items on hand. Each cf tiicse Ouee opt-i ations may be ^ecified in a separate request, 

1 5 but each operation should only be perfonned if all three operations can be performed. In osder 
to properly detejinine that buying stock item A, selling stock item B and updating the 
inventory are from the same single transaction requires that transaction state infortnation be 
retained by the servicing process that receives the three requests. 

One possible solution to the stateless problem is to spawn & servicing process for each 

20 request-issuing source (each "cliait"). Each time a request from a client is received, the same 
sen'tciisg process is called upon to process the request. Because the same process is invoiced 
for a given client, the transaction state information for a particular transaction can be 
maintained by the associated servicing process, feus allowing for the processing of multiple- 
request transactions. 

25 This solution has sigaiitcant drawbacks, however. First, tnaintaimng a separate 

servicing process for each client is waste&I since most clients do not continually make 
requests to the servicing process. Between client requests, the sen^icing process simply waits, 
consuming system resources, without performing any work, A second drawback with this 
solution is that it is non-scalable. If a servicing process is spawned and maintained for each 

30 client, ^em resources would quickly be consumed, even for a relatively small number of 
clients. Therefore, spawning a servicing process for each client is not a viable solution for 
lar^e scale systems. 
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A second possible solation tis to require each servicing process to maintain the cutrefit 
state of tibe iransacUons that it is caimitly processing. By njajntaiaing tmisactjon state 
infotmation, each servicing process can ensure that multiple-request transactions are 
processed correctly. However, a drawback associated with requiring each servicing process to 
5 maintain transaction state information is tfost it puts a burden on the developer of each 
servicing process to write extra code in order to maintain the r^uired ^ramaction state 
infortnatioa. 

Based on tJie foregoing, U is desirable to provide a mechanism for processing nsolttple- 
request transactions in a stateless environment that does not require a servicing process to 
1 0 maintain transaction state information. 

SLMMARY OF TIIE imTNTION 

The present mventjor. prosidcs a practical and htgWy scalable mechaj^tsm for 
condtscting rfnilltijle-requesl transactions io a stateless environtTjent, such as tha. web. 

1 S According to the invention, a traj5sactioft matiager is used to coordinate the overall transaction 
process, Pi«ferab!y, the trasisaction manager coordinates the process in such a way that state 
information is maintained for a transaction without requiring the transaction manager itself to 
persistently maintain the state infonnation. 

In a preferred embodiment, processing of a client request is performed as fellows. The 

20 transaction manager receives a request from a client, and if the request is & transaction request, 
the msaiager initiates a transaction with a transaction processing mechanism, saich as a 
database management system (DBMS). Once the transaction is initiated, the manager 
prejferabty forwards the request to another entity, such as an applicaiion, which actually 
processes the request. After the request is processed, oontml is returned to the manager, and 

25 at that point, tibe manager assembtes a set of state information associated with the transaction. 
This state information may include the id^tity of the climt« the ID and status of the 
transaction, and what has aiready transpired in the transaction. Once assembled, the stale 
information, along with the response to the client request, is sent back to the client to be 
maintained by the client The state information may be sent to the client in the form of a 

30 "cookie" or it may be incorporated into a UBL that is returned to the client. While it is 

possible to do so, state information is preferably not persistently maantained by the manager or 
by the plication that processed the request. 
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Wh«n the cisent submits a second request nMim to the same traasactioa, ibe client 
sends along the state information i^eviously provided by the manager. Upon receiving the 
second request, the manager extracts Uie state infoimation fiom the request, uses it to 
resume the previously imtiated transaction with the DBMS. Once the transaction is resumed, 

5 the manager sends the second reque^ including the state information, ^ ajiother entity (the 
same or a different ^pUcatioia} for pFOcessing, After the second request is processed, the 
manager updates the state inforroation associated with the transaction, and sends the updated 
state infonnation, along with the response to the second request, to the eiient The client will 
send this updated state infonnatSoii t« a future reque^ to resume the transaction. Has process 

1 0 repeats «ntil the transaction is either committed or rolled back. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The present inveotion is iilustrated by way of example, and not by way of limitation, in 
the figures of the accompanying drawings said in which like reference numerals refer to 
1 5 similar eiements and i n which ; 

Figure 1 is a block diagram of a computer sptem upon which an embodiment of the 
invention may be impiemersted; 

Figure 2 is a b lock diagram of a distributed ^plication server according to an 
embodiment of the mv«jtion; 
20 Figure 3 A is a portion of a flow chart iUustrating steps for handling a browser request 

according to an embodiment of the invention; 

Figure 3B is another portion of the flow chart iU««traisng steps for handling a browser 
request according to an embodiment of the invention; 

Figure 4 is a block diagram of a table contajning information maintained by a 
25 dispatcher accordir^ to an embodiment of the invention; 

Figure S is a block diagram of a table containing infbmiation maintained by a resouiee 
manager according to aa embodiment of the invention. 

Figure 6 is a block diagram of a distributed application server for processing 
ttansactions according to an embodim<ajt of thie invention; 
30 Figure 7A is a portion of a flow diagram illustrating steps for processing multiple- 

request transactions in a stateless environmeiit according to an embodiment of the invention; 
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Figwre 7B is ^tfeer portion of »he flow diagram iJlus»ating steps for processing 
mo!tiple-reque$t transactions in a stateless environment acco«!bg to «i emljoditneftt of the 
iovoition; 

Figure 7C is another portion of the flovs* diagram illustrating steps for processing 
5 muJtipJe-request transactions in a stateless environm«3rt aceording to an emtKxliment of the 
inv««tion; 

FiguKJ ?D is another portion of the flow diagratn iHiistrating steps for processing 
multiple-request transactions in a stateless environnjent acco«Jing to an mibodiment of tbe 
invention; 

10 Figure 7E is another portion of the flow diagrani illustrating steps for pnjcessmg 

mxjitiple-mquest transactions in a stateless environment according to an embodiment of t he 
invention; 

Figtna 7F is another {wrtion of the tlow diagram iHustrating steps for processing 
multiple-request transactions in a stateless iKiviromnent according to an embodiment of the 

IS invention; 

Figure 7G is another portion of the flow diagram il?ustrating steps for processing 
multiple-request transactions in a stateless environment according to af5 embodiment of the 
invention; 

Figtxre 7H is another portion of the flow diagram iUastrating steps lor processing 
20 muhiple-raqncst transactions in a stateless envitomnent according to an embodiment of the 
invention; and 

Figure 7! is anotiber portion of tii»e flow diagram illtjstrating steps for processing 
multiple-request transactions in a stateless eHviKjnment according to an embodiment of the 
invention. 

25 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

A m^od jutd apparatus for processing multiple-request transactions over a network is 
described, la the following description, forth© purposes of explanation, numerous specific 
details are set forth in order to provide a thorotigh wnderstanding of the pt5esent inv<sition. It 
30 will be apparent, however, to one skilled in the art that the present inv^ition may be practiced 
whhont these specific details. In other instances, well-Jmown structures and devices are 
shown in block diagmm form in order to avoid unnecessarily ohscunng the present invention. 
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HARDWAjRE OVERViEW 
Figure ! is a block diagram that iltastTates a compTater syst«ai 100 upon which an 
embodim^t of the tnventioo may be implemented. Computer system 100 includes a b«s 1 02 
or other coinmunication mecba«j$m for comtnuaicattng infonnation, asd a processor 104 
5 coy|}]«d with bus 102 for processing iofonnation. Computer system 1 00 also includes a main 
memory 106, such as arandom access memory (RAM) or other dynanjic storage device, 
coupled to bus 102 for storing mfermaticm and instmciions to be executed by processor 1 04. 
Main memory 106 also may be used for storing temporary variables or other intennediate 
mformation during execution of instojctions to be executed by processor 104, Computer 

10 system 100 further includes a read only memory' (ROM) iOS or other static storage device 
coupled to bus 102 for stonng statsc sT^fommlion and instnictions tor processor 104, A storage 
device 1 10, such as a nsagnetic disk or optical disk» ispatovided and coupled to bus 102 for 
storing information and instmcttons. 

Computer system 1 00 may be coupkd via bus 1 02 to a display ! 1 2, mch as a cathode 

1 5 ray tube (CRT), for displaying iiifomtatiori so a computer user. An input device I H, 

including alphanumeric and other keys, is coupled to bus 102 for commyitjcating infonnation 
and command selections to proce^ssor 104, Another type of user input device is cursor control 
1 1 6, such as a mouse, a tnickball, or cursor direction keys for communicating direction 
infonnation and command selections to processor 1 04 and for controlling cursor movement on 

20 display 1 12. This input device typically has two degrees of fteedom in two axes, a first axis 
(e.g., X) and a second axis (e,g,, y), that allows the device to specify positions in a plane. 

The invention is related to the use of computer system 100 to perform specific 
operations in response to messages from brawsesK. AcconJing to one embodiment of the 
invention, the opmtions are perfonned by computer system }00 in response to processor 104 

25 executing one or more se(|uences of one or more instructions contained in main memory 106. 
Sach instructions may be read into main memory 106 ftom anotiier computer-readable 
medium, such as storage device 1 10. Execution of the sequences of instmcttons contained in 
main memory 1 06 causes processor 104 to perfoixn the process stqjs described herein. In 
alternative embodiment, hard-wired circuitiy may be used in place of or in combination with 

30 software instructions to iir^lonmt the invention. Thus, embodiments of the invention arc not 
limited to any specific combination of hardware circuitry and software. 

The term "computer-readable medium" as used herein refers to any medium that 
participates in providing instructions to processor 104 for execution. Such a medium may take 
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many toms, including bat iK>t limited to, »on-volatiie media, volatile media, aad transmission 
media. Non-voMle media includes, for example, optical or magnetic disks, sadi as storage 
device 1 10. Volatile media includes dynamic memory, such as main memory 106. 
Transmission media includes coaxial cables, copper wire and fibesr optic«, including the wires 
5 that comprise bas 102, Tiansmission roedia can also take the form of acotsstic or iight waves, 
such as those generated during radio-wave a»d inira-red data communications. 

Common forms of computer-readable media include^ for example, a floppy disk, a 
flexibie disk, hard disk, jwagnetic tape, or any other magnetic medium, a CD-ROM, aijy other 
optical medswm, punclicards, papertape, aiiy other phsysical medium with patterns of hoies, a 

1 0 RAM, a FROM, and HPROM, a FLASH-EPROM , any other memory chip or cartridge, a 
carrier wave as described hereinafter, or any other niedjum ftom wiiich a computer can read. 
Various forms of computer readable media may be involved in carrying one or more 
sequences of one or more irtstmctions to processor 104 for execution. For example, the 
instructions may initially be carried on a magnetic disk of a rtimote a^mputer. The remote 

1 5 computer can load the instructions into its dynamic memory and send the i nstmctions over a 
telephone line u,sing a modem. A modem local to computer system 1 00 can receive the data on 
the teiephone line and use an infra-red transmitter to convert the data to an infra-red signal. An 
iti&a-red detector coupled to bus 102 am receive the data carried in the inlra-nsd signal and 
pJace the data on bus 102. Bus 102 carries the data to main memory 306, from which processor 

20 1 04 retrieves and executes the instructjons. Tlie instniciions received by main memory 1 06 may 
optionally be stored on storage device 110 either before or after execution by pjxwessor 104, 
Computer syst&n 100 also inchides a communication interlfece 118 coupled to bus 102. 
Commumcation iaterfat;* 1 18 jsrovides a two-vi^ay data communication cotqjliag to a networic 
link 120 tiiiatis connected to a local networfc 122. For example, cwnmanication interface 1 18 

25 may be m intei^ed services digital networft (ISDN) canj or a modem to provide a 

commumcation connection to a conesponding type of telephone line. As another example, 
communication interface 118 may be a local area netwosic (LAN) cani to provide adata 
communication connection to a cotnpatible LAN. Wireless links may also be implemented. In 
any sudi in^lenteot^on, commumcation interface I IS sends and receives electiica!, 

30 electromagnetic or optical signals Stat cany digital data streams rsj»ssenti«g vatious types of 
information. 

Network link 120 typically provides data communication through one or more 
networks to other data devices. For exaniple, network link 120 may provide a connection 
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through local network 122 to a host computer 124 or to data equ5pm«Rt operated by an 
Internet Service Provider <ISP) 126. ISP 126 in turn provides data commaxacation semces 
through the world wide pack«* data commanication networic now cotamoniy inferred to as the 
"Internet" 128. Local netwotk 122 and Internet 128 both a$e eiectrJeal, elcctromagnetjc or 

5 optical signals that carry digital data streams. The signals thioagh the varioas networks and 
the signals on networic link 120 and through commumcation interface US, which cany 
digital data to and from computer system 100, are exemplary fottns of carrier waves 
transporting the information. 

Compiiter system 1(K) can send messages and receive data, indwdirig progran> code, 

10 tlMX)ugh tlie iiet\vork:(s), network link 120 and commuiiication interface 5 1 8. in the Internet 
example, a server 1 30 might transmit a requested code for atJ application progrsim Uwough 
Internet 128, ISP 126, tocahietwotk J 22 axtd comn^mkatsosi interface 1 1S. 

The received code may be executed by processor 104 as it is received, and/or stored in 
storage device ! 1 0, or other non- volatile storage for later execution. In this manner^ compota' 

J S system 100 may obtain application code in the form of a carrier wave, 

FUNCTIONAL OVERVIEW OF APPLICATION SERVER 
Figure 2 is a biock diagram of a system 200 designed according to an embodiment of 
the invention. The system 200 includes a plurality of browsers 202, 204 and 206 that 

20 communicate with a plwality of listeners 2!0, 216 and 222 over tbe internet 208 according to 
the HTTP protocol. In response to requests from the browsers, the listeners cause a web 
application server 280 to invoke software modules, referred to herein as cartridges. In the 
illuslTated esnbodiment, web application server 280 has initiated the execution of tiaw 
cartridges 230, 234 and 238. 

25 The web application serv^a- 280 is composed of numsrous components, including 

traiasport adapters 212, 218 and 224, dispatchers 214, 220 and 226, an authentication server 
2S2, a virtual path manager 250, a resource manager 254, a configuration provider 256 and a 
plurality of cartridge execution engines 228, 232 and 236, The various components of the wcJ> 
application server 2S0 shall be described hereafter in greater detail. 

30 Significantly, &e numerous components of web ^plication server 280 commanic^e 

through an inter-machine communication mechanism, such as m Object Reque^ Btoker 282. 
Using an inter-machine comimumcation mechanism, cartridge instances that perform the 
operations specified in browser requests may execute on diffis'ent machines than the Jistenei* 
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that receive the requests and the browsets that issue the rsqiwsts. Because the cartridge 
ifistaaces are on <liffersnt machines than the listeners, the listenei« are better insulated against 
faulty cartridge instances, thus enhancing the reliability and secwtty of file system. In 
addition, the scalability of the system is greaUy incteased by spreading the processing burden 
5 of executing the cartridge instances among many machines, rather than the same m achine that 
is executing the listener. The ability to distribute cartridge instance execution across muUipIe 
machines allows numerous types of load balancing techniques to be used in deciding when 
asd where to spawn new cartridge instances. 

A typical operatioa within system 200 generaHy includes the foSlowsng stages; 
10 A browser transmits a request over Internet 20S. 

A listener receives the request and pa,sscs it through a transport adapter to a dispatcher. 

The dispatcher communicates with virtuai path manager 250 to identify a cartridge 
selected by the browser request and to detettnine whether the cartridge requir<« aathentjcatiot) 

If the cartridge requires authentication, the dispatcher communicates with the 
1 5 authentication server 252 to detenu ine whetlier the browser is authorized to access the 
seiecled ciirtridge. 

If the authentication server 252 determines that the browser is not authorized to access 
the selected cartridge, the browser js notified that access has been denied. 

However, if access is authorized or the virtual paOt manager 250 determines that 
20 authentication is not req[uired, the dispatcher does one of two things. If the dispatcher knows 
about an untised instance for that cartridge, the dispatcher sends the request to that instance. If 
there are no tmused cartridge instances for tJiat cartridge, the dispatcher asks the resource 
manager 254 to create a new cartridge in^aace. After the instance starts up successfiilly, the 
cartridge ttottfies the resource manager of its existence. The resource manager 254 tfien 
25 notifies the dispatcher of the new instance. The disjjatcher creates a revised teqne&t based on 
the browser request and s^tds the revised request to the new instance. 

The cartridge instance handles the revised request and sends a response to the 
dispatcher. 

The dispatcher passes the response back throa^ the listener to the client, 
30 These stages shall be described in gnsater detail hereafter. 
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CARTRI0OES 

Cartridges are modules of code for p^formmg i^eeific application or system 
fiinctions. A <^Ttri4ge forms the basic unkofdistribution in the lystem 200^ Accoidiitgto 
one embodiment of the invention, cartridges are named using Univetsaj ResouKie Locators 

5 (ORLs), Thus, a cisitridge name {i,e, IJRL) has two parts: the IF address of the server on 
which the cartridge resides, md tha virtual path in the server directory structure of the 
cot«f>i{ed cartridge code. Because cartridges are named using URLs, the cartridge name space 
is global and cartridges may be accessed using the same messaging techniques as are used to 
access other web resources, such as docimients. 

10 According to one embodimeiu of ihe invention, each cartridge has a stai^dard interface 

which provide* a common overall slmcture for aU cartridges. The siatidard interface defines 
the interface of raatjBes that are invoked by tiie web application server 280 under particular 
conditions. According to one embodiment of the invention, the abstract cartridge interface is 
as follows: 

1 5 interface Cartridge 

I 

boolean init(); 

boolean authenticate(in Principal userjjasswd); 
boolean cxcc<in Request retjjohj, ont Response resp_obj); 
20 boolemj shntdownO; 

\ 

The initO routine is r^ponsible for tntialtzing the cartridge instance. This may include 
invoking the constmctors of several subobjects, preforking ajreads and acquiring all other 
required shared resources, 
25 The shutdownO loutine is respottsible for cleaning up ail of th6 resotnces and sijutting 

down the cartridge instaiwe. Once the sh«tdown() routine is invoked on a caitridge instance, it 
immediately becomes unavailable for servicing stJbseqtient requests. 

The authenttesteO rotitine validates whether the client requesting the services of the 
eartridge is authorized to use those services. 
30 The ©tecO routine is the generic way to dispatch all stavice requests to the cartridge. 
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EXEMPLARY CARTSTOES 
Each cMridge is eather configured as a cartridge that performs a welUdefined fanctjon, 
or as a programmable cartridge that acts as an inteipretrar or a routine mviromneat for an 
^plication. An exajtnple of a programmable cartridge is a PL/SQL runtime, configored to 
5 process database qvtmes according to the Oracle-based Prograiriming Lsngtia ge using 
Structured Queiy Lasguage (PljSQL). The PL/SQL nmtiiTte executes a browser request 
having a database <5«er>'. The PL^QL rantlme processes tl>e request, for example, by 
acccssiRg a database server in communication with the cartridge insta3>ce via a data Sink, 
^teother exfjmpie of a progranimable cartridge is a J AVA runtime interpreter. The 
10 JAVA nmtime inter]5reter cartridge enables web application devebpers to write server-side 
JAVA applications to process bro%vser request. Similarly^ a custom server may be configured 
as a cartridge in order to provide d>mam!c operations s«ch as, for example, accessing 
processes executed by a third party scj-ver, 

IS DISPATCHERS 

Di&'patchei^ are software moduies coniig«rsd to route the requests received by listeners 
to the appropriate cartridges. According to one embodiment of the invention, dispatchers are 
impiemented as server-side program extensions (i.e. "plug-ins"). As such, the dispatchers are 
loaded into and execute within the same address space as the listeners to which they betog. 

20 The dispatchers may be linked with the listener code at compile time or dynamicaUy loaded at 
runtime. 

la the illustrated embodiment, di^alcbers 21 4, 220 aaid 226 are associated with 
Jisteoeis 210, 2!6 and 222, respectively. Dispatchers 214, 220 and 226 selectively route 
browser requests received by Hstsners 210, 216 and 222 to cartridges. 
25 For eatample, assume that listener 2 1 0 receives a browser request over the Internet 208 

delivered in the form of a Uniform Resource Locator (URL). The biowsor request serves as 
an identifier for a web object, for example an HTML page or an operation to be perfonned. 
The listener 210 hands off the browser request to dispatcher 214 without any attempt at 
interpreting the browser request- Upon receiving tire browser request, the dispatcher 214; 
30 (i) communicate wiflv virtual path manager 250 to id^tify a cartridge selected by the 

browser r^uest and to determine whether the carfeidge requires authentication, 

{2> if the cartridge requires authentication, C4>mmtmtcates witii the authmtication 
' server 252 to determine whether the brov^^er is allowed to access the selected cartridge, 
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(3) if access is au&orized, communicates with the resource manager to detOTaim the 
specific iostance of the selected cartridge to which the browser request should be sent, and 

{4) creates and di^atohss a revised browser request for execution by the specified 
instance of the cartridge. 
5 The revised browser request repackages information received in the original browser 

request. The revised browser request may include, for example, a context object that contain 
data required for the proper operation of the cartridge. The data re<|uired ibr proper operation 
of a cartridge may include, for exatspie, a transaction ID that identifies a transaction with 
which the browser request is associated, - 
U) if the cartridge replies to tije req uest, the cartridge sends tl^se r<^ly to the dispatcher and 

the dispatcher passes the reply up to the listener for transmission to the browser that initiated 
the request. 

CONFIGURATION PROVIDER 
! 5 According to one embodiment of the invention, cartridges that are to be u.sed with web 

application server 280 are first registered with web appJication server 280, During the 
registration process, information about the cartridges is supplied to the configuration provider 
256. Configuration provider 256 stores tlK- information as metadata 258 for later access by 
the components of the web ai^lication server 280. 
20 The metadata 258 may include, for example, 

{!) the cartridge name; 

(2) the minimum number of required instajces; 
<3) the maximum number of instances; 

(4) the location of the code that implranents the cartridge; 

25 (5) the program-dependent iunction names used by the cartridge execution engine to 

execute the callback fimctions {initialization, request handler, shutdown); 
(€) a list of machines for running the cartridge; 

(7) the idle time for flte cartridge (the amount of time inst^ss of the cartridge are 
allowed to remain idle before they are shut down); 
30 (8) an object identifia; and 

(9) data indicating the tj^e of authentication service, if any, to be used with the 
cartridge. 
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The object identtfier gxjcifies the data that mtjsl be supplied by a browser request for 
requesting performance of m ojjeration by the corwspondmg cartridge. The object type may 
be a specific word, a URL, or may irtctode a virtual path $wclj as 'VJava", 

Once configiaatios provider 256 has stored the configuration information for a 
5 particular cartridge in the metadata 258, that cartridge is automatically registered when web 
application server 280 is started. 

After a cartridge is r«;g!Stered with the web application SKrs'er 280, tlic resource 
manager 254 inidates the minimum instances for the canridgt.'. Once tr>!.! inininiiim number of 
instances has been initiated, the web appHcatton server 2 SO is prepared to process browser 
10 requests. 

THE VIRTUAL PATH MANAGER 
As mentioned above, dispatchers commimicate with the virtual path manager 250 to 
determine where to route each revised browser request. Specifically, eacii browser request 

1 5 typically includes a URL. Upon receiving a browser request, the dispatcher sends the URL in 
the request to the virtual path manager 250. The virtuai path manager 250 responds by 
sending the dispatcher data that identifies the cartridge, if any, associated with (he UiiL. 

In order to supply the required information to dispatchers, virtual path manager 250 
consults the metadata 258 that maps URLs to cartridges. In response to receiving a browser 

20 request, the virtual path manager 250 uses the maj^ing data to deteimine the cartridge, if any. 
to which the UKL contained in the browser requests corresponds. 

For iacample, if the browser request is a URL request begiiaang wife tJje virtual path 
"/Java" the mapping may indic^e that the lAVA iatetjaeter cartridge is configured to handle 
requests having the virtual path "/Java". 

25 According to one embodiment of the invention, the vj ttual path manager 250 also 

detetmintes whether ttie carttidge associated with ttie URL requires authstttication. If the 
cartridge requires authentication, the virtaai path manager 250 indicates tn the response that 
the -^rtual path manager 250 sends to the dispatcher that authentication is required, if 
atithentication is not required, the dispatcher creates and s«(ids a revised browser request to an 

30 instance of the cartridge witttout invoking the aiith^tication server 252, If authentication is 
required, the dispatcher sends the revised request to an in^ce of the cartridge only after the 
aulhentbation server indicates that the revised rsquest may be submitted to an instatjce of the 
cartridge. 
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THE RESOURCE MANAGER 
The resource manager 254 of the web application server 2§0 manages the otecistion of 
each of the csrUidges by initiatiag a predetermined mimmam number of instances for the 
cartridges, load balaociag between the instances of each cartridge, and initiating new instanfces 
5 of cartridges as necessaiy up to a predetermined tnaximum mmh&r of instances of a given 
cainidge. 

For example, assume that the metadata for a partkulaT cartridge <C3) includes the 
foliowitig information: 
Name-C! 
10 Mimmimi instances =^ 10 

Maximant Insiaiices 50 
Host Machines -Mi, M3, MS 
Idle time 30 seconds 

1 5 Based mi this metadata, when cartridge C J is first registered, resource manager 2S4 

will initiate ten instances of Ci . Resource manager 254 will initiate ftie ten instances on ftie 
machines associated with the labels M I , M3 and M8. 

Upon receipt of requests ftom dispatchers to access C!, resource manager 254 
deteimines whether any existing instance of Ct is available for use. If no instance of CI is 

20 available when a request is received, resource manager 254 determines whetiier the maximum 
number of instances of Ci are already running. If the maximum number of iastaaoes of C I 
are not abeady running, then resource manager 254 initiates a new instance of Cl on one of 
the possible host machines and transmits a message that identifies the new instance to the 
dt^atcher that issued the request. If the maximum number of instances of Cl are already 

25 running, then resource manager 254 sends a message to the dispatcher that is^ed the request 
to indicate that the request cannot be handled at this time. 

LOAD BALANCING 
According to one embodiment of ttie invention, resource manager 254 applies a set of 
30 load balancing rules to det«Emine where to initiate instances of cartridges where there is more 
than one possible host machine. Thus, in the above example, MI, M2 and M3 are aiJ capable 
of executing instances of cartridge Ci. If Ml, M2 and M3 have the same processing capacity, 
it may be desirable to distribute the inst^ces evenly across the three machines. However, if 
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Ml has ten times the prxjcessing power of M2 and M% it may be desirable to ioitiate all 
instances of CI m Ml up to a certain point, asxA then ta distribute additional instances evenly 
among Ml, M2 and M3. 

To assist resource manager 254 in determining how to load baianee among possible 
5 machines, tbe metadata stored for each cartridge may (nciude additional detaiis. For example, 
th« metadata may specify a separate mmimum and maxinjum number of instatices for each 
machine. Resource manager 254 may then disttibute new instances aniong the machines 
based on which machine has the lowest ratio of actual inst^ces to maxtmum instances. 

The metadata may also specify an order for the machines that can mn a cartridge- The 
!0 machine at the N+l position in the order is only used to execute instances of the cartridge 
when the machine at the Nth position in the order i$ already executing its maximani number 
of instances. 

CAKTRtDGE rNSTANCE STATUS TRACKING 

1 5 According to one embodiment of the inventicai, the r^urce manager 254 maintains 

state infonnation to keep track of cartridge instances that have been CK^ted. The state 
infoimation inolndes data that identifios the instance, identifies the machine executing the 
instance, and identifies the hstener to which the mstence has besn assigned* 

Fipre 5 illasti^tcs a table 500 that may be maintained by resource manager 254 to 

20 store this state infonnatjon. Table 500 includes an instance column 502, a cartridge column 
504, a listens column 506 and a machine column 508. Each row of table 500 cowesponds to 
a distinct cartridge instasice. Within the row for a given cartridge instance, cartridge column 
504 identifies the cartridge associated with the cartridge instance and instance column 502 
indicates the instance number of the cartridge instance. For exarnqpie, row 510 corresponds to 

25 an instance of cartridge CI . Therefore, cartridge column 504 of row 510 indicates cajtridge 
01 . Instance column 502 of row 510 indicates that the cartridge instance associated with row 
5 10 is instance I of cartridge CI. 

Listener column 506 indicates the listener to wlilch the cattridge instance associated 
with a row has been assigned. Machine colimm SOS indicates the machine on which the 

30 cartridge instance associated with a row is executing. For example, the cartridge instance 
associated with row 5 10 has been assigned to listens 21 0 and is executing on machine Ml. 

Similar to resource manager 254, each dispatcher maintains state information for the 
cartridge instances that Mve been assigned to the listener to whi<^ the dispatcher is attached. 
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Such state infomiation may be maiistajned, for example, m a table 400 as shown in Figure 4. 
StmUar to table 500, table 400 iRctodes an instance column 402 mi a cartridge column 404 
that respectively hold instance msnbers cartridge identifiers. However, wbile table 500 
includes one entry for every cartridge instance assigned by resource manner 254, table 400 

5 only includes mtries for cartridge instances that have been assigned to a particulsff listsmer. 
For example, table 400 includes entries for only those cartridge instances listed in table 500 
that have been assigned to listener 210. 

In addition to instance column 402 and cartridge column 404, table 400 inciisdes a 
status column 406. For each row, the status coliunn 406 holds a value that indicates the status 

1 0 of the instance associated with the row. For exiutiple, the status column 406 of row 408 

jftdicates that instance I of cartridge CI is cutrently busy. In the illustrated embodiment, the 
status column 406 holds a tlag that indicates that a cartridge instance is either BUSY or FREE, 
The significance of the cartridge status shall now be describe with reference to Gie opmstion 
of resource manager 254 and dispatchers 214 aiid 220, 

15 

INTER.A.CTION BETWEEN D1SP.A.TCHERS AMD 
THE RESOURCE MANAGER 
As explained above, dispatchers communicate with resource manager 254 wh^ they 
need to,send a revised browser request to a particular cartridge. According to one 
20 embodtment of the invention, dispatchers fjrst determine whether an instance of the 

appropriate cartridge (1) has already been assigned to it and <2) is available to process the new 
revised browser request If an a|>piopriate cartridge instance has already been assi^ed to the 
dispatcher and is currently available to process the new revised browser request, then the 
dispatcher forwards the revised browser request to the caatridge instance without fttrther 
25 ctHnmumcation v/ith resource manager 254, 

For example, assume that listener 210 receives a browser request ttiat, according to 
virtual path manager 250, must be processed by cartridge CI . Assume also that table 400 
reflects the current list and status of cartridge instances that have been assigned to iisteaer 
2 10. Upon receiving the browser request from listener 210, dispatcher 214 inspects table 400 
30 to locate a FRBE instance of cartridge CI . In the illustrated table 400, i^jw 410 indicate that 
instance 3 of cs^dge CI is currently FREE. Consequmtly, dispatcher 214 forwards a 
revised browser request directly to instance 3 of cartridge CI without ferther communication 
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with resource manager 254. In response to sendmg the revised hcmms reqtiestj, di^atcher 
214 changes the status value in status column 406 of row 410 to BUSY. 

If a listeaer has not already been assigned m appropriate cartridge instance that is 
currentiy available, then the dispatcher associated with fee cajtridge i^uests a cartridge 
S instance ftom the resource manager 254. If the resource maitager 254 determines that m 
instance of the required cartridge is not available and the number of existing instances of ti>e 
ngquired cartridge is below the njaximum, then the resoaree njgui^er 254 initiates a new 
caitidge. Upon initiating a new cartridge, the resource manager 254 inserts an entry for Uie 
new cartridge instance in table 500. 

1 0 Assiimc% for example, that listener 2 1 0 receives a browser reqtjesi that must be 

proeessed by cartridge C3, Assume also that instancs 3 of cartridge C3 hm mt yet bsen 
initiated. Under these conditions, dispatcher 2 1 4 sends to resource manager 254 a request for a 
handk to an instance of cartridge C3, In response to this request, resource maaager 254 
initiates ins tance 3 of cartridge C3 on machine M3, In addition, resource manager 254 inserts 

1 5 into tabic $00 the entry found at row 512. 

After inserting row 5 1 2 for instance 3 of cartridge C3 in table 500, resource manager 
254 sends back to the dispatcher 2 i4 a handle to the newly created instance. In response to 
receiving this handje,, dispatcljer 2 14 inserts an entry (row 412) for the new instance in its 
status table 400. The dispatcltor 214 then transmits a revised browsssr request to instance 3 of 

20 cartridge C3- 

I?BLEASING CARTRmOE INSTANCES 
According to one embodiment of the itivention, listeners do not atrtomatically release 
ownership of cartridge isstances when the csstridge instances finish responding to outstanding 
25 browser requests. For example, assume that instance 3 of cartridge C3 receives a revised 
browser request, processes the revised browser request, and sends a re^onse bacic to 
dii^J^cher 214. Dispatcher 214 passes the re^nse to listener 210 to be sent back to the 
browser that issued the browser request. 

At this point, listener 210 no longer requires ownenjhip of instance 3 of cartridge C3. 
30 However, rather than transferring ownership of instance 3 of cartridge C3 back to resource 
manager 254, dispatcher 214 njerely changes the stams column 406 of row 412 ftom BUSY to 
FREE. 
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Changing the value m stanjs colutran 406 of row 412 to FREE mdicates &at instaiice 3 
of cartridge C3 is no longer working oa a request, and Js therefore ready to handle salJseqneot 
requests. However, because t^le 400, which Indicates that instance J of caitridge C3 is 
available, is njaintained locally by dispatcher 214, instance 3 of cartridge C3 is only available 
5 for subsequent browser requests arriving at listener 210. Row 512 of table SOO maintained by 
resource manager 254 coatmues to indicate that instance 3 of cartridge C3 is owned by 
list«ier210. 

Because listenets do not aatoanaticaliy release cartridge instances every time a request 
is serviced, overhead associated with communication between the resource manager 254 and 

K) the varioas dispatchers is sigaificantty reduced. For example, assume that a listener 210 
receives ten successive requests that must be cosnmunicated to carti-idge C3, Rate than 
communicating with resource mamager 254 for each of the ten requests, dispatcher 2 1 4 may 
communicate with resource manager 254 in response to the first request. The subsequent niiie 
requests can be handled by dispatcher 214 without communicating with resource manager 254 

15 because the dispatcher 214 uses the same instance of C3 that processes the first request to 
process the nine subsequent requests. 

While not automatically releasing listener ownsrstup of cartridge instances when each 
request is serviced can increase the efficiency of web application server 280, listeners cannot 
maintain ownership of cartridge instanc<» indefinitely. For example, instances that have not 

20 been used for long periods of time slwuld be passed back to the resource manager 254 so they 
cjm be de-allocated to &ee up resources. In addition, it is not efScient for one listen^' to 
maintain owneis^up of the instance of a cartridge that it has not used for a relatively long time 
when other listens require instances of that c»tridge> 

Consequently, resource manager 254 communicates to each listener a maximum idle 

25 time for each cartridge instance passed to the listener, tbe maximum idle time indicates the 
maximum amount of time a cartridge instance can go tinused before the listener mast release 
ownership of the cartridge instance. For example, assume that the resource manager 254 
indicates to listener 210 that the maximum amount of idle time for instance 3 of cartridge C3 
is 10 minutes. Based on this information, listener 210 may continue to use instance 3 of 

30 cartridge C3 to process browser requests for cartridge C3 as Umg as instance 3 of cartridge C3 
does not remain idle or FREE for more than 10 mmutes. 

If instance 3 of cartridge C3 Is Idle for more than 10 minutes, dispatoher 214 removes 
row 412 fi-om table 400 and sends a message to resource manager 254 that listener 210 is 
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reJeasing ownership of mslarjce 3 of cartridge C3, to re^ns« to this mess^^s. ^uree 
manager 254 updates row 512 to indicate that iastasKe 3 of cartridge C3 is not owned by any 
listener and may thus be resssigned to anotijer listener or tenninated. 

In an alternative embodiment, dispatdhers do not aotomatically release cartridge 

5 instance$ when the id!e time for the caittidge instance has expired. Instead, the dispatcher 
sends a message to resource manager 254 offering to release the expired instance. Resource 
manager 254 may respond to tiie offer by requesting that the listener release the cartridge 
instance^ or by allowing the hste«er to retain ownership of the expired cartridge instance. 
According to one cmhodtment of the ifsvent-on, resource manager 254 roajntains a 

] 0 queue of the requests that cannot be immediately ser\'iccd. When it becomes possible to 
service a queued reque$t, the request is removed from the queue and processed- 

For example, assume that hsteiier 222 receives a browser reqiiest that must be 
processed by cartridge CI, and that listener 222 has not beet) assigned any iostances of 
cartridge Cl . Dispatcher 226 sends a request for m instance of CI to resource manager 254. 

15 Assame further that a maximum of 50 instances of Ci are allowed, and tiiat 50 instances of 
Cl have been assigned to listener 210. Under these conditions, resource manager 254 cannot 
service the request from listener 222. Therefore, resource Kjanager 254 ptits the re<}ue$t o« a 
queue. WItea listener 210 releases an instance of Cl > resource manager 254 comnuinicates to 
listener 222 that an instajtce of Cl is available, 

20 Under certain conditions, resource manager 254 may preemptively cause a listesier io 

release a cartridge instance. For exanjple^ n^urce manager 254 may detect a system 
overload situation and respond by terminating a set of cartridge mstances, eiiJjcr before or 
after informing the Usteisters that ctjrrently have been assigned the cartridge instances that the 
cartridge ins^nces are ^ing to be terminated. 

25 Resounse manager 254 may also preemptively cause listeners to release cartridge 

inst^ices to implement fairness policies between listeners. For example, resource manager 
254 may cause a Ustm^ that holds the most instances of a given cartridge to release an 
invstance of the cartridge when another listener has waited more than a predetermined 
threshold of amount of time for an instance of the cartridge. For example, if listener 210 has 

30 been assigned 50 instances of cartridge Ci and Cl has a maximum of SO insfcmces, then 
resource manager 254 may cause listener 210 to nelease an instance of Cl ten seconds after 
receiving a request for an instance of Cl fbm anottisr listener. 
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CARTRIDGE EXECUTION ENGINES 
Aceordtng to one emboditnent of the bveatJoa, each cartridge jn^ce is composed of 
a cartridge execution engine aad a cartridge, A cartridge execution engine is a code module 
that insulates cartridges from fee complexities of the web ^plication server 280 a«d the inter- 

5 moduie commumcation mechanism. A cartridge is made available to a cartridge execution 
engine by storing in a fimction table pointers to the cartridge fonctions. Accotrfing to one 
embodiment, a!l cartridges provide the functions specified in the exemplary casftridge interface 
described above. By having all cartridges support the same interface, a single standard 
cartridge exeeution engine can be used with ail cartridges. 

1 0 According to one embodiment of the invention, Ciirtridges are impkmenied as shared 

iibraries, aild cartridge execution engines are executable programs that invoke the routines in 
the shared libraries using the standard cartridge interface. The cartridge execution engiise 
provides the interface between cartridges and the dispatcher, directs cartridge flow of control, 
and provides smdces for cartridges to ase. 

1 5 When the resource matxager 2S4 requires the creation of a new cartridge instance, the 

resoOTce maitager 2S4 causes a cartridge execution eugine to be instantiated. In turn, the 
instance of the cartridge execution engine thus created causes the appropriate cartridge to be 
instanttated. The resonrce manager 254 can cause the cartridge execution engine to be 
instantiated, for example, by irtvoking a "caitridge execution engine factory** that resides on 

20 the machine on which the cartridge is to be executed. The instance of the cartridge execution 
engine can catise the cartrid^ to be ittstantiated, for example, by malcing a call to one of tihe 
routines in the shared Uhrary that constitutes the cartridge. 

As shown in Figunj 2, the web application server 280 includes cartridge execution 
engines 228, 232 and 236 for each of the cartridges 230, 234 and 238. The cartridge 

23 execution engines control execution of the instances of the corresponding cartridges by 

making calls into the cartridges througj* the standard cartridge intcarfece. By establishing basic 
callback functions between the cartridge execution engine and a cartridge, any cartridge can 
be integrated into the web application server 280 by configuring the cartridge to respond to the 
callback functions, and then registering the cartridge in the configuration provider 256, as 

30 described below. 

Thus, if the dispatcher 214 determines that the FL/SQL runtime cartridge is tiie 
appropriate cartridge to process a request, the di^atcher 214 dispatches the request to a 
cartridge instance that includes a cartridge execution engine associated with the PL/SQL 
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nmte caitriage. If a new instance nee4s to b« mitsated, fte resoai^e manager 254 cjeates a 
new instance of the fUSQt rmtbrn cartridge in a separate atidress space mi 4tspstch«$ the 
request to the cartridge execation engine 228 of the new mstancc. The address space used to 
execute the instance of the program may be within m«moty of the computea- system upon 
5 which one or more of flje components of web appUcatton server 2S0 is executing, or on 
another computer systmu 

In response to a message frnm a dispatcher, the cartridge execution mpm issues a 
request handler callback ftmction to thu- cartridge, causing the cartridge to process the rcquest, 
The cartridge executing the request reiums the result to the cartridge executiDn engine, which 
10 foru'ards the result to the dispatcher. \n the event that tiic web appiication server 2S0 detects a 
fault in the operation, the cartridge eteculicn cniunc {jsucs a shutdown function of the 
canridge. 

Hence, the canridge execution engine provides an application programming interface 
to the web application server 280 ihiit specifies predt-tennined operations to be perfontned. 
1 5 Use of the standard cartridge interface enables progranuners of the cartridges to configure 
eaclt cartridge for high -level integration into the web application server 280 independent of 
the protocols used by the particular web listener with which the cartridge will be used. 

TRANSPORT ADAPTERS 

20 Listesiers enable tiie use of server-side plug-ins by providing a ptogiamming intcrfaice 

and pnstocol for use by such ptng-ins. Unfortunately, the progfamming inter feces and 
protocols provided by listeners vary ftom listener to listener. For example, Netscape Server 
Application Programming Interface (NfSAPI), internet Server Application Programming 
Interface (ISAPI) and Application Development Interface (ABI) ai© three examples of distinct 

25 prognutuning interfaces currently provided by listeners. 

Transport adapters insulate di^8tcb«« fkom the proprietary protocols and interfaces 
used by web listeners. Specifically, each transport adapter is confignred to recognize the 
protocols of dtfferesnt listeners, and to convert the browser requests received ftom the listeners 
into converted browse requests having a standard dispatcher protocol that is indepertdeat 

30 from the protocol of ttie lisiener. Similarly, transport adapters convert the replies from the 
dispatcher to the transport protocol of the listenetsi. 
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Hence, tb« transport adapter enables the web application server 280 to foe ased with 
Hsteners from different veiidors. Moreover, tmssport adapters may be conSg«i«d to 
accommodate different server a«jhttect\jres and q>er^5ng systems. 



5 OPERATION OF THE WEB APPLICATION SERVER 

Figiires 3 A and 3B are a f sow diagram iHastrating a method of responding to a browser 
request according to an embodiment of the present invention. The browser reqnest is received 
m step 350 by a listener. For the purposcsS of explanation, it shall be assumed that the kowser 
request was issned by browser 202 and received by i i stener 210. 

!0 Upon receiving the browser request, the listener 2 1 0 fomaids tl)e request to the web 

application server 280 in step 352. Specificaliy, listener 210 passes the re<juest to the 
transport adapter 212 usitig the proprietary progfamming interface of the Jistener 210. The 
transport adapter 2 i 2 converts the request as necessiiry to p<5ss the request to dispatcher 2! 4 
using a standard dispatcher programming interface. 

1 5 Dispatcher 2.1 4 identifies the request object tv-pe that corresponds to the hmwm: 

request in step 354 based on the virtual path speci Oed sn the browser request by 
communicating with the virtual path manager 250, If the request object type corresponds to a 
cartridge, the virtya! path manager aiso indicates to the dispatcher 214 whetber authentication 
is required. 

20 The dispatcher 114 detenninss in step 356 if tite request object type corresponds to an 

identifiable cartridge. If the reqtJest object type does not correspond to m identifiable 
eartridge, the request is returned to the listener 210 in step 35S (see Figure 3B}, If in st&p 358 
the listener 210 recognizes the request as a reqtiest for a static HTML page, the listener 
accesses the static HTML page, and sends the HTML page to the browser 202 in step 360. If 

25 the browser request is not recognized by the listener 210* the reply is sent to Sie browser 202 
in step 360 indic^^ng that the request was unreco^iaaabie. 

If in step 356 the dispatcher 214 determines that the request must be sent to a cartridge, 
then the dispatcher performs any necessary authentication by communicating with the 
authentication server 252. The authentication pi»cess will be described in greater detail 

30 hereafter. In addition, if in step 356 it is determined that listener 21 0 has not been assigned 
any instances of that cartridge that are cwrently FREE» then the dispatcher 2 \ 4 comiminicates 
with the reasonrce manager 254 to be assigned an instance of the cartridge 230 to which the 
browser request can be sent. 
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in step 362, shown in Figur© 3B, the reso«me manager 2S4 determmes whether an 
instance of the identifjed cartddgs is available (imowned) among the <?X5Sttng msmber of 
instances. For th« purposes of explanation, it shall hs assumed that the reqiuest is associated 
with cartridge 230, and that cartridge 230 is a PL/SQL runtime cartridge. 

5 If i« step 362 the resowrce manager identifies an available instance, for example 

mstance 260 of the PL/SQL nmtime 230, the lesoarce manager 254 tp/omis the dispatcher 
214 that the request should be sent to instance 260 The dispatcher 2 4 then cieates and srads 
a resj-fd &nw<cer ft qu.':;' to Mie cartndge execution engine 228 of the ins.tance 260 m step 368 
t:> cc»«-5f tnc jiUhL 'n,t n.o 2(>if to oroct<.<! the requei>t, as descnbed below 

10 Ho\\ i* n ',!tp -ifiJ no instance of the oanndgt^ 230 is avail iblu tnc fe^ODrcc 

maiiaget 2*"'^ dctt,rra. c 1 1 ^tL^'> '04 if t-xs&tmg numbet of jistiijces, cv<.tt.db a mixnnain 
prt&vnbcd numbe'- If tht i,x s sng nunibcr of nT-tanu-s, exceed the maxinrjum pre<5cnbeci 
number n step "^64, the re^iouioc ma \igcs 2'^4 ijidst^ales to the dispatcher 254 that *he reqi est 
cannot be proc<,$$t.d at this tnnt rei>oonse, the dispatcher 2 1 4 re*urn' thv. ttque it to ti^c 

1 5 listener 210m step 35S, after which the w«-b listener 210 sends a reply to the browser 202 over 
the netwck m '-tep "^60 -idscattrg the request -svas not processed 

Alteniat.vel> when cartridge mstance js not currently avadablc to handle a request, 
listener 2 1 0 mav p.aee the reqt.« st on a waitmg list for that cartndge mstance Wheti a 
cartridge instance becomes available, the revised browser request is removed from the vsraiting 

20 list and forw^ed to the cartridge instance. If the revised browser i«q«est remains on the 
waiting list for more than a predetermined amount of time, lisientsr 210 may remove the 
request &om the waiting list a«d send a message to the browser 202 to indicate that the request 
could not be processed. 

If in step 364 the existing number of instances does not exceed the maximum 

25 prescribed number, the resource manager 254 initiates a new instance of ^e identified 

program and infonns the dispatcher 214 that a revised browser request hused ou the browser 
request should be sent to the new instance. The dispatcher 214 then dispatches a revised 
bmwser request to the cartridge execution engine of the new instance. 

For ejcample, assume that resource manager 254 initiated instance 260 in response 

30 to the browser request. Daring the initialization, the stored sequences of instrticttons for the 
PL/SQL runtime are accessed to create a new instance 260 of the cartridge 230 in an address 
space that is separate 6»m the address space in which dispatcher 214 is ex^uttng. According 
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10 one embodiment, mittslizatjon is perfonned by loading the cartridge executjoit engme 228 
and having the cartridge execution m^m call the initiaiixatbn routine itit cartridge 230, ■ 

Once the new instance 260 isS ninning, the dispatcher 214 dispatches the request to the 
cartridge execution engine 228 associated with the new instance 260 in step 368. The catridge 
5 execatjon engine 22S sends a callback message to the new instoce 260 i«questing execution 
of llie request. In the callback message, fhe cartridge execution engine 228 passes any 
param^m necessary for the instance 260 to process the request. Such parameters njay 
include, for exaropie, passwords, database search keys, or any other argmnent for a dynamic 
operation executed by the instsmee 260. 

3 0 The instiUJce 260 then executes the request. Dunng the execution of the request by the 

instiujce in step 362, the dispatcher 214 monitors the inst ance to determine the occurrence of a 
fault in step 370. If in step 370 the dispatcher 214 detects a fault, the dispatcher 214 calls the 
corresponding cartridge execution engine 228 in step 372 to abort the instance 260 having the 
fauh. The cotTe«pondiiig cartridge execution engine 228 in turn i.<5sue$ a shut down command 

1 5 across the AFl to the fauUy instatice. The instance, responding to the shut down cotmnand by 
the cartridge execution engine 228, will shut down without affecting any other process in any 
other address space. 

If in step 370 no fault is detected, the dispatcher 214 receives a r^ly from the instance 
260 upon completion of ^ecutioa in step 3?4. The dispatcher 214 in step 376 forwards the 
20 reply to the listener 210, which responds to the browser with the reply from the executed 
instance 260. After executing the instance 260» the dispatcher 21 4 in step 378 maintains the 
instance in the memory, as shown in step 378 to enable execution of a subsequent request. 

DISTRIBUTED AKCHTrECTURE OF WEB SERVER 
25 Significantiy^ the various components of the web application server 280 communicate 

with each other using a communication mechanism that does not requtns the components to be 
executing in the same address space or even on the same machine. In the illustrated 
emboditaeot, the compoisents of the wefc aj^Jhcatton server 280 are configured to 
communicate through an Object Request Btoker (0KB) 282. Object Request Brokers are 
30 described in detail in "Common Object Reque^ Broker: Architecture md Spectficatjon 

(CORBAr, This and other documents relatitig to CORBA can be found on the World Wide 
Web at http;//wwvVffi^y|g;.org . 
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Whilo the embodiments of the preseat iaventjon shall be d<5$cribed with reference to 
communicatjons throagb a CORBA-cornpliant ORB, other cross-ptetfbnn communicatioa 
mechanisms may be used. For example, ths conjponents of web application serv^ 280 may 
alteraaiively c^iaum<^te with each other using Remote Procedate Calls (RPC), a UNIX 

5 pipe, Micmsoft COM. 

Because die varioas compouents of the web application server 280 coiumtrntcate with 
each other using a machine independent conTmanicatSon mechanism, there are no inherent 
restrictions with respect to where the components are located with respect to each other. For 
exampSe, Usteaers 210, 216 at\d 222 may be executing on the same maehijie, or on three 

1 0 completely different machines, each with a different operating system. Similarly, the 

authentication server 252, vimsaS path l«anager 250, resource manager 254 and conftguration 
provider 256 may be executing on the same machine or on fotjr different machines. Further^ 
those four different machines may not have any overlap with the three machines executing 
listeners 2 1 0, 2 1 6 and 222, 

15 ' Cartridge execution engines 228, 232 and 236 incorporate all of the necessary logic to 

commynicate with the other components of the web application server 280 through the object 
request broker 2S2. Consequently, the location of the cartridge itistarsces themselves is not 
inherently restricted by the eommunication mechanism: Thus, instance 260 may be executing 
in a completely diSferent machine and operating syst«tn than dispatchers from which it 

20 receives reqaests. Likewise, instance 260 may be on a different machine and operating 

system than the lesowrce manager 254 or arty of the other components of the web applicattoa 
server 280, including instances of other cartridges Uiat are being managed by the same web 
application server 280. 

SigRtficatitly, the tocatio«-indfi?)end*aice enjoyed by cartridges used by web 

25 application sender 280 is achieved through fee oaitxidge execution engine communication 
logic, not through any custom programming in the caittidges themselves. Consetjaently, the 
cartridgss do not need to be speotally designed for execution in a distributed application server 
enviroimient. Cartridge designers are thus insulated fiwmte complexities of a distriba^ " 
system, and can concentrate their eiTorts on the logic associated with the tasks for which the 

30 cartridges were created. 
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PROCESSING TRANSACTIONS 



According to aa mihodmmt of the iBveatioti, trajmctitsns ar§ Implemented in a 
stateless ^vironmcut thmugh the use of metadata that iiKlicates specific in&rmaijon for 
specific types of transactions. A piece of iafomjation about a transaction ttiat is supplied in 
5 the m^6m i$ mtms4 to herein as an attribute of the transaetton. The use of metadata to 
indicate specific attributes of a transaction allows for a system in which cadges are not 
s-eq«ired to persistently maintain state infonnation. Trat^&actions in such a system are 
deckrativc rather than programmatic in Uiat Ihe messages themselves indicate the transactions 



to which they belong. For example, the meiadata for two particular types of twtnsactions, TX1 
10 and TX2, could be as follows: 



[TXlj 

[STOREFRONT] 



«ame - STOREACCOUNTS 



15 



belong-to-list « /STOREFRONT 
/BANKING 



resource-list «= i^SEARS 



/BANK! 



begin ~- /storefront/open session 
commit « /store&ont/commit sassion 



20 



loUback - /storefixjnt/roUback session 



25 



ITX23 

[EMPLOYEE) 

name « BMPLOYEBACCOUNTS 
belong-tO'list «^ /EMPLOYEE 

mAmme 



resouice-iist =»'/PERSO^!NEL 



/BANKl 



30 



begin »■ /«»p}oyee/ope« session 
eotimat « /employee/commit semm 
rollback /employeeftollback session. 
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For each type of transaction the metadata iacludes various attributes. According to 
one embodjtneot. attributes mdude a cartridge name, a traasactioa name, a beiong-to-Hst, 
a resource-list, begin, commit and rollback TRANSACTION URLs> In the exmiph given 
above, the cartridge name for TXl, is STOREFRONT, the transactioji name is 

5 STOREACCOUNTS, the belong-to-Iist eonsists of /STORBFRO^^r md /BAMONG, the 
resource-iist consists of /SEAKS and /BANKl , the begin traiisaction URL is /storefront/^open 
session, the commit transaction URL i$ /storefront/commit session and the roJiback 
transaction, URX. is /storefent/roUback session. 

The cartridge nsme attribute tderitlfies the particular lypt of cartridge that the 

1 0 dispatcher communicates with to perform ;he operations of the. transaction. The transaction 
name attribiste uniquely idsjntitles the type of traissactior; rtjialive to other transaction types. 
The belong- to- list of s transactsors type ii,?;5s ihc cartridges that may participate in the 
per^om^anc^; of the transaction. The resource-Ust ts the iist of resources that are affected by the 
performance of transactions that are of the transaction type. Tb,e begin tran.saction URL i$ the 

15 URL that signals that a traaisaction of this type is about to begisi. The oimmit transaction URL 
is the URL that stgnal$ that a tran-saction of this type Uiat is currently in progress should be 
committed. The roilback transiiction tIRl. is the URL that signals that a transa<^on of this 
type that has already started should be rolled back. How each of these attribute values is used 
during the p^formaace of a transaction ^all be described in greater detail below. 

20 

TRANSACTION OVERVIBW 
Figure 6 is a bJock diagram of a system 600 that provides for the processing of 
muUSpte-re^ue^ transactions in a stately enviroiuneait accorditig to one embodiment of the 
invention. Figure 6 is similar to Figure 2 and therefore Hke components have been numbered 
25 alike. Within this document, the term browser request and the term transaction reqtjest are 
used interchangeably. The t«tm multiple-request transaction is used to refer to a single 
transaction that is comprised of two or more browser requests. 

As described earlier, cartridge execution engine 12% commmncates with a plurality of 
dispatchers (e.g. one or more of di^atchers 214, 220 and 226) through object request broker 
30 282 to receive browser messages. These browser messages may be sent from a plurality of 
browsers connected to the Internet 208. In addition to the plaraiity of dispatchers, cartridge 
execution engine 228 also communicates with a cartridge 2S0, configuratioii provider 256 and 
transaction mans^er 606. As previously described above, the cartridge 230 represents a 
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mottole of code that is either configured as a cartridge that |)crfo«»s a wcU-defined fmjctio», 
or as a prngrammable cartridge that aets as an interpreter or a routine enviionmerit for m 
application. The combination of cartridge execudon engine 228, transaction manager 606 and 
cjKtridge 230 constitute a cartridge instance. 

5 A partical^ cartridge may be associated witis a plurality of database servers for access 

to a plurality of databases. In this exaetnpie, cartridge 230 has the ability to process database 
transactions according to the Structured Query Language (SQL) by accessing database 610 
and dataibase 614 throu^ dalabase server 608 and database server 612Tesp6CtiveJy. 

Transaction manager 606 represents a coordinating module that is associated witb 

1 0 cartridge execution engine 228 and functions to coordinate the execution of multspte-request 
transactions in the stateless web enviroivment. In cooKliaattng the execution of multiple* 
rcquesJ transactions, {lansaction manager 606 retains no slate information for th« muUiple- 
request transactions, Tije transaction manager 606 communicates with cartridge execution 
engine 228 So receive transaction conJi'ol njessages. Using tht infornrdtion contained in the 

IS transaction control messages, the transaction manager 606 interacts with database servers 60S 
and 612 to cause changes made daring muUipie-request transactions to respective databases 
610 and 614 to be either committed or rolled back as an atomic unit of work. 

IDENTIFYING TRANSACTIONS 
20 ' Browser requests thai are associated with multiple-request transactions include a 

globally unique transaction ID. The giobaliy tjoique transaction ID within a browser request is 
tised to identify the mtiltiple-request transaction to which the browser request belongs. 
AcconJing to one embodiment, when a browser request is received that contains a begin 
transaction URL, the transaction manager creates a globally unique tr8ma:tion ID. This 
2S globally unique transaction ID is returned to die serjding browsisr, and is sent by ttie browser 
in subsequent browser requests that are associated with the same multiple-request transaction. 

In certain embodiments, when returned to the browser from which a muHipte-request 
transaction was initiated, the globally unique transaction ID associated with the paaticular 
muMple-reque^ transaction is stored as cookie information on the client executing the 
30 browser. When a subsequent bmwser request is sent by the browser, the dispatcher determines 
if the subsequent request contains a begin transaction USX,. If the request does not contain a 
begin transaction XML, then the dispatcher obtains the globally unique transaction ID 
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associated with the browser request by reading the sending bmwser's cookie infoimation 
using the HTTP protocol standards. 

For example, when a bmwser 202 sends a first browser request associated W!& a 
transaction and a begin transaction URL, the tmnsaction manager 606 creates a unique 
5 browser identifier and smds it to the dispatcher 2!4. The dispatcher 214 then causes the 
globally unique transaction ID to be stored as cookie information on browser 202. When 
browser 202 sends a second browser request that is associated with tibe same transaction, the 
dispatcher 214 obtains the globally unique transaction ID contained in the cookie infoimation 
of browser 202. 

10 Using the giobatly unique trarssaction ID, the database servers that nltimately process 

ti>e browser request can deiennine that both the first browser request and the second browser 
request are associated with the sanie muitiple-request tratj&actioR, Because a particular 
browser may be executing more than ons transaction ai a time, in certain embodiments, the 
cartridge name for the particular transaction is cont-ained within each globally unique 

15 transaction ID and is used to help identjfy the particular transaction to which the globally 
unique transaction ID correspond.^. 

In certain situations cookie ijifom^ation may not be available on a particular bnawser. 
For example, a particnlar browser may not support ih& use of cookses or a particular wser may 
choose to deny access to the browser cookie information. Therefore, in certain embodiments, 

20 the transaction identifiej« are embedded in the messages retunsed to a browser, and sent out by 
the browser in subsequent browser requests. This can be accorapltshed by anjiotating (he 
URLs that are associated with the hyperlinks of the HTML page that is resumed to the 
browser 202. Based upon the glt^ally unique transaction ID that is sent o«t as part of the 
btomu request DHL, the database servers that uititnately perform the operations specified in 

25 the browser requests can use the globally naiqtie transaction ID to identify the multiple' 
request frmtsaction to which each particuiar browser request belong^. 

TRANSACTION CARTRIDGE rNSTA^mATION 
Each browser request contains URL information that is sent fiom the sending browser 
30 in response to a user of fee browser selecting a hypertext link on an HTML page. The UBL 
information includes a Usifona Resource Indicator (URI) portion and a header section. The 
URl portion includes transaction state information and a cartridge name. The tPMisaction state 
infort»ati<m is used to identiiy the particular state of a multiple-request transaction. The 
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cartridge name is used to identify the cartridge type and allows the cartridge ©cecutton engine 

to identify the metadata that is associated with the browser request 

The header section is used to store a globally unique transaction ID thai is used by die 

database servers to identify the muitiple-iequsiit transaction that is associated with a particular 
5 transaction request 

Wh«o a listmer i«ceiv<s tt»e browser request* it passes tbe browser request to the 

dispatcher. The dispatcher then communicates with the virtual path manager to determine the 

caartridge type that is associated with the b«3wser request, In one embodiment, the dispatcher 

forwards the information contained in theURI to tlie virtual path Tnaasger. Using the 
1 0 infermation in the UM, the virtual path manager communicates with the cot»fjgttr«tion 

provider to detennine the cartridge t^^pe that is asaocsated with the browser message. 
Once the cartridge type is identified, the vsttual path masiager returns data that 

identifies the cartridge t>'pe to the dispatcher. The dispatcher then searches a cartridge 

instance pointer iist that includes pointers to cartridge instances that have previousiy been 
15 associated with the particuiar dispatcher. If the dispatcher locates a pointer to a cartridge 

instance that is of the cartridge type that is associated with the browser request, the dispatcher 

uses the pointer to send a revised browser message to the cartridge instance. 

I f the dispatcher does not iocate a pointer to the type of cartridge instance that is 

associated with the ferowsear request, the disftatcher communicates with the resouisce manager 
20 to obtain a cartridge instance of that typet. In obtaining the cartridge instance, the dispatcher 

sends a message to the resource manager that includes die caitndge type that was previousfy 

identified by the virtual path mapper. 

Upon receiving the dispatcher message, the resource manager determines if a cartridge 

instance of the request type is available for use by searching a cartridge instance pointer tabte, 
25 If a cartridge instance pointer of the requested type is located in the cartridge instance pointer 

table, the resource manage sends a pointer to the avail^le caj^ridge instaitce back to the 

dispatcher. 

However, if a caitfidge instance of the requested type is not available, the resource 
manager catjses a cartridge instance of the request type to be instantiated. 
30 In one embodiment of the invention, the resource manager causes a cartridge instance of the 
requested type to be instantiated by requestittg a particuiar cartridge factory process to create a 
cartridge instance of the request type. Cartridge factory processes may be located across 
muitiple machines. When a particular cartridge factory process is requested to instantiate a 
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cartridge instance, it instantiates the eartridge instance on the same machine that the caitridge 
factory is ciarently executing on. Therefore, fee resource manager seiects which earfeid§e 
factoiy to use based on iho pHticnlar machine the tesouK:e manager chooses to instantiate the 
cartridge instance. 

5 Upon receiving a lequest to instaatiate a cartridge instance, the cartridge factory 

process instantiates m instance of a caraidge execution engine, Otsce the cartridge execution 
engine is instantiated, the cartridge execution mgine obtains the transaction iiifon-nation, if 
any, that is associated with the requested cartridge type. For example, if the requested 
cartridge type is of t>'pe STOREFRONT as described in TXt ahove, Oie cariridge execution 

10 engine obtains and stores the metadata information that is associated with TXl. This metadata 
jnfonnation \s used by tise cartridge instance to process transactions. 

After ofataiotng the metadata information, the caiiridge execution engine instantiates a 
cartridge of the requested cartridge tj'pe. The instance of the cartridge that is created is 
dyr^amicaily linked with the cartridge execution engine. The cartridge execution engine then 

1 5 . instantiates a transaction manager. The transaction manager instance is dynamical !y linked 
with the cartridge and the cartridge execution engine to form a cartridge instance. 
Once the cartridge instatjce is fonned, the transaction manage* uses ttie metadata information 
that was previously stored by the cartridge execution engine to open connections with the 
databases that were identified in the resoorce-list of the njeta<3ata. These connections are 

20 retained by the transaction manager and later used to provide database handles to the 
associatod ci^dge md to control the processing of ranltiple-reqiiest ttaaisactjons. For 
example* if the requested cartridge type is of type STOREFRONT, the resounie-ljst is 
associated with a SEAKS and BAHKJ database. Using the resource-list information, the 
transaction manager opens a connection with the SEARS database and the BANK! database 

2S by respectively establishing connections with the database servers associated with the SEARS 
mtd BANKl databases. These comiections are wtained by the transaction manager and are 
used for processing tr^isactions of type TXl . 

After the transaction manager establishes its connections with the appropriate 
databases (i.e. through the database swvers associated with the appropriate databases), the 

30 cartridge execution engine notifies the cartridge factory that a cartridge instance has been 

instantiated by returning a pointer to the cartridge instance back to the cartridge factory. Upon 
receiving the cartridge instance pointer, the cartridge factory $eRd.s the cartridge jnstaaoe 
pointer to the resource manager. 
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The r«soi!rce manager then registers the csrfriclge insfance pointer mto its c^4ge 
instance pointer table. The resource manager then seods the cartridge instance pointer to the 
dispatcher. Upoo receiving the cartridge instance pointer ftom the resource manager, the 
dispatcher ^ores the cartridge instaace pointer into its associated eaitridge instance pointer 
5 Jist. The dispatcher then uses the cartridge instance pointer to send a revised browser message 
to the carttidge instance. 

CR£ ATJHG REVISED BROWSER MESSAGES 
Upon obiainjBg a cartridge instance pointer, tl>e dispatcher creMes a revised browser 
1 0 message using the- mfomiation associated vviih the browser request. This revised browser 

message includes ihe URI, header inforn^alion, the cartridge type and a disp^chcr pointer that 
allows messages to be returned to the dispatcher. For example, a revised message for a 
transaction of type TXl &s described above, may include the foilowing information: 
URI = /storefront/open^session 
IS header -NIJIX 

cartridge rsame - [STOREFRONT] 
dispatcher pointer address XXXXX 

In this exampie, the IMl is a be^n transaction URI <a URI that is used by the cartridge 
20 execution engine to identiiy the begitming of a moltiple-reque^ transaction). Becatjse the 
URI is a begin transat^on URI, a globally unique transaction ID has not yet been associated 
with the multiple-request transaction. Hence, the header that would coritain the transaction ID 
is set to NULL. For ongoing multiple-request transsaetions (i.e. when the browser request does 
not contain a URI of /storefipont/openjsession)and in whidh cookies are used to store the 
2S globally nnique transaction ID, Ihe header will contain the unique transa<^o» ID. This unique 
transaction ID allows the database servers to assoeiate a transaction i«q«est with an ongoing 
multlple^request transaction. 

The cartridge name identifies the cartridge type and is n«ed by the cartridge execution 
engine to idaitily the metadata to contains infoiroation about the transaction type associated 
30 with the particular browser request. In this example, the cartridge name of STOREFRONT 
id^itifies the metadata associated with TXl as being associated with the browser mqumt 

After creating the revised browser message, the di.spatcher uses the previously 
obtained cartridge inst^ice pointer to send the revised browser m^sage to the cartridge 
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instance. When the cartridge mstance re!ceive$ the tevised browser message, the cartridge 
instance oses the cartridge type informaUon to identify the metadata tiul is associated with the 
browser request. Aftex tdeutifykg Oie metadata, the cartridge execution engine uses the UJU 
infonnation to determine the stsate of the traa^sacticm associated with the iwowser rejjujsst. 

5 For ex^le, it shall be assnmed that the browser raqtiest included a URI of 

"Morefionfopsn„session" and a cartridge type of STOREFRONT, 

By looking at tt\s metadata associated with the cartridge type of STOREFRONT (i,e, 
the metadata described in TX 1 above), the cartridge execution engine 228 deteimines that the 
URI of /store&ont/open_,sess!on corresponds to a ^'begin" transaction state. Using this same 

1 0 mechanism, the cartridge execution engine 228 can determine that a browser request 

containing a URI of Morefront/corninit^session corresponds to a "commit" transaction state 
and that a browser request containing a URI of /stt»efronJ/roilb«:fc_session corresponds to 
a"roiiback" transaction state. 

In the case where the URI does not include a particular stale (i,e, a URI consisting only 

1 5 of /storefront), the cartridge execution engine 228 assumes that the browser request is 
associated with an ongoing raultiple-request transaction that is not ready to be either 
committed or roiled backed. 

When the cartridge execution €3tgtne receives a reviised browser tnessage that is not 
associated with a "b^n" transaction, the cartridge execution engine checks the header to 

20 determine if it specifies a globally tinique transaction ID. If the header specifies a globally 
unique transaction ID, then cookie information was used to store the globally unique 
transaction ID. If the header does not ^ecify a globally aniqae transaction ID, the cartridge 
execution engine then searches the URI to identiiy the globally tinique transaction ID that is 
associated with the browser request. Oia:e the cartridge execution engine locates the globally 

25 omque transaction E), the csutridge execuh'on engine includ*^ the transaction ID in the 
transaction contiol message that are sent to tht transaction manager. The transaction 
nianager then uses the globally unique transaction ID in comtntjoicating with the associated 
database servers to cause multiple-request b^sactions to be either committed or tolled back 
^ an atomic unit of m«k, 

30 

PROCESSING TRANSACTIONS 
Fignre ? A through 71 are a flow diagram illustrating a method 6>r fjiocessing multiple' 
request transactions m a stateless environmetit according to an embodiment of the in^tion. 
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At step 702, a ttmstsi browser message that was directed to cartridge 230 m 
intmjepted by cartridge cacecution mgine 228, For tlie purpose of explanation, it shatl be 
assiBtJcd that the revised browser ajessage was stsnt by dti^atcher 214 arid that the tevjsed 
browser message is associated with trsBsaction TXI as described above, 

5 At step 104, cartridge execution engine 228 determines if the revised browser message 

JS associated witli a transaction- If the revised browser message is not associated with a 
transaction, at step 706, cartridge execution engine 22S forwards the revised browser message 
to cartridge 230 for cartridge 230 to perform She requested non-transactional functions 
associated with the revised browser message. Once the cartridge performs the requested nm- 

10 tra«sactso«al functions, control returns to step 702 in order for the cartridge ex«c\iUon engine 
228 to intercept tiie next revised browser message. 

Otherwise, if tiie revised browser message is associated with a transaction, at step 708, 
cartridge execution engine 228 determine.? ttie .state of Jhe tr-ansaction by first determining 
whether the revised browser message is associated with a begin transaction URI. In 

15 detennining whether the revised browser mes.^age is associated with a begin transaction URI, 
the cartridge execution engine 228 uses the cartridge narae to identify the previously stored 
metadata that includes the transaction attributes of the transaction typts identified in the revised 
browser message. Using the previously stored metadata, the cartridge execution engine 22S 
detatmines iiih& revised browser message is associated with a begin transaction URI. 

20 For example, it shall be assumed that the revised browser message contained a 

cartridge name of STORJEFRONT and a URI of /storefiront/open^scssion. Using the 
STORBFRONT cartridge name, the cartridge cxecation engine 228 determines that Use 
revised brovs^s^- message is associated with the metadata for transaction TXI . Using this 
metadata, the cartridge execution «»gine 228 determines that the URi of 

25 /storefront/openjsession is associated with a begin transaction. 

If the cartridge execution engine 228 determines that the revised browser message is 
not associated with a begin transaction, then control proceeds to step 744. 

if the carhidge execution engine 22S deteimines that the re'wsed browser message is 
associated with a begin transaction, thm at step 712, tiie cartridge execution engine 22S 

30 includes a begin t!«tjsaction identifier (tx„begin) in a transaction control message. The 

cartridge execution engine 228 then sends the transaction control message to the transaction 
msajsger606. 
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At step 714, upon iwemng the Ijcgia transaction jdmtigar. the transactioa maaager 
606 creates a globally miqm trmactitm JD that is wsed to identify s«bse«|uent browser 
requests that are associated with this multiple seqiKst transaction. In certain embodiRjeats of 
the itiventioft» the tra«sactio» ID is formed using the bmwser IP address, the transaction name 

5 and a particular ttntestamp vait)e» 

At step 716, the cartridge execution engine 228 sends an operadon message to 
cartridge 230 that is Jbnned fipom infom^ation that is containtjd in the revised browser 
message. The operation message also includes a dispatcher pointer that ideniifies the 
dispatcher that sent the revised browser request (dispatcr.er 2 \ 4). Hiis pointer aJiows the 

1 0 cartridge 230 to write inforaaation back So the dispatcher. At step 718, upon recetviog the 
operation message, the cartridge 230 sends a message to the transaction manager 606 
requesting handles for access to the databases (hat are associated with the U-ansactioo. 

At step 720, transaction manager 606 retums handles to the appropriate database 
servers to aUow the cartjidge 230 to process the transaction request. For exampie, assuming 

i 5 database 610 is associated with the SEARS database and database 614 is associated with the 
BANK! database, transaction tnanagsr 606 will return hai^les to database server 608 and 612 
respectively. 

At step 722, cartridge 230 uses the handles returned from transaction manager 606 to 
execute the operations identified t« the op^aration message that was sent by the cartridge 
20 execution engine 228, 

At sa^ 724, the cartridge 230 determines whether the serjding browser allows cookie 
infonnation to be associated with the browser, M the browser does not allow for cookie 
information to be associated with the browser, at stq> 726. the cartridge 230 causes the 
hyperlinks of the HTML p^e th^ was genmted i« response to executing this trsnsactiofn 
25 request to be annotated to include the globally utjique trsuasactioti ID, By samotating the 

hypsrUnks of the HTML page» the tJRIs contained in subsequent browser request will contain 
the giobally unique transaction ID- 

At stqj 728» the cartridge 230 uses the dispatcher pointer to return back to the 
dispatcher 2!4 laie HTML page that was generated in response to executing the transaction 
30 request, The cartridge 230 then notifies cartridge exectition engine 228 that execution of ttie 
transaction request is complete, 

At step 730, the cartridge execution engine 228 sends a message to the tj^sactton 
manager 606 requesting it to suspend the transaction. At step 732, the transaction manager 
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606 sends a susp^d request to database servers 608 and $12 to cause them to suspasd 
execatson of the transaction. The suspend inequest ijjctudes the glotjally unique transaction ID 
so that the database servers 608 612 know which ftansacttoit to suspend. By seisdiug a 
suspend request to database servers 608 and 612, tt allows other browsers to execute 

5 transactions thm are associated with datalmes 610 and 614. 

At step 734, transaction manager 606 sends the globally unique transaction ID to the 
cartridge execution engine 22S. At step 736, the cartridge execution engine 228 determines 
whether the sending browser allows for cookie infonnation to be associated with the browser. 
If the browser does not allow for cookie iafom^ation to be 2s.socjated with the browser, at step ' 

10 738, tise dispatcher 2 1 4 is notified tiust She processing of the revised browser request is 
complete. Control then returns to sjep 702 to intercept aijoiher revised browser message. 

If the browser does allow for cookie itiformatjoii to be associated with the browser, at 
step 740, the cartridge execution engine 22S uses the globally unique transacttou ID to create 
cookie information to be associated with the sendinjg browser. 

1 5 At step 742, cartridge execution engine 228 forwards the cookie infomiation to 

dispatcher 2 1 4 so that it may be transmitted "to the sending browser and notifies the dispatcher 
214 that the processing of She revised browser request is complete. Control then rehiras to st^ 
702 to intercept another revised browser me-ssage. 

At step 744, the cartridge execution engine 228 determines whether the revised 

20 browser message is associated with a commit transaction URI. In determining whether the 
revised browser message is associated with a commit transaction URJ, the cartridge execution 
engine 228 uses Hie cartridge name to id«ttify the previously stored metadata &r the type of 
transaction associated with the revised browser message. Using the previously sto«id 
metadata, the cartridge execution engine 228 determines if the revised browser message is 

25 ^ociated with a commit transaction URI. 

For example, it shall be assumed that the revised browser message contained a 
cartridge name of STOREFRONT and a URI of /storefironl/commit^session. Using the 
STOREFRONT cartridge name, the cartridge execution csfjgtne 228 detennines that the 
revised brtjwser message is associated with the in^ata for transaction TXl . Using this 

30 metadata, the cartridge execution engine 22S determines to the URI of 
/storefiont/commit„ses$ion is associated wife a conunit transaction. 

If the cartridge execution engine 22B determines that the revised browser message is 
not associated with a commit transacttoiu then control proceeds to step 774. 
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If the carfaidge exeaition engine 228 d«termines that the revised browser tnessage is 
associated with a cammH transactioa, then at step 746, the cartridge execution engine 22S 
determines whether the header section of the revised browser message contains cookie 
information. If cartridge execution engine 228 determines that the header section of the 
S revised browser message contains cookie information, then at step 748 the cartridge execution 
engine 228 extracts the globally unique transaction ID from the cookie information. Cwittol 
then proceeds to 752. 

if cartridge execut ion engine 22S determines that the header section of the revised 
browser message does not contain cookie information^ then at step 750 the cartridge execution 
10 eogSBe 228 extracts the globally unique tninsaction ID frosn the annotated UHi 

At step 752, the cartridge executtoa engine 228 packages a restimc traasactioa 
identifier (tx^resume) into a transaction control message. The cartridge exectttion engine 22S 
then sends the transaction controi message to the transaction manager 606, 

At step ?54. upon receiving the resume transaction identifier* the transaction nian^er 
1 5 606 sends a resume request to database servers 608 and 6 1 2 to cause them to resume 

execution of the transaction. The resume request includes the globally tmiqtte transaction ID 
which aiiows the database servers 608 and 612 to identify the muttipte-request transaction that 
is associated with the cuirent transaction request. 

At st^ 756, the cartridge execution engine 228 sends m operation message to 
20 cartridge 230 that is based on the transaction information contained in the revised browser 
message. The operation message also contains a dispatcher pointer that identifies the 
dispatcher that sent the revised browser request (dispatcher 214) and allows the carteidge 230 
to write information hack to the dispatcher. At step 758, tipon receiving the opoaiion 
message, the cartridge 230 sends a message to the transaction manager 606 requesting handles 
25 iot access to the databases that are associated with the transaction. 

At step 760, transaction maaa^ 606 fetams bandies to the appropriate database 
servers to allow the cartridge 230 to process the transaction request. For example, assuming 
database 610 is associated with Ote SEARS database and database 614 is associated with the 
BAMKl database, transaction manager 606 will return handles to database server 608 and 612 
30 respectively. 

At step 762, cartridge 230 us(js the handles returned from transaction manager 606 to 
execute the operation specified by the operation message that was sent by the cartridge 
execution engine 228. 
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At stq) 764, the cartridge 230 determioes wfcethef the setidiug ferowsar al!ows cookie 
mformation to be associated with the bmwser. If the browser does not allow for cookie 
infonnation to be associated with the browser, at 766, the cartridge 250 causes the 
globally unique tmxsaction ED to be removed from the annotated hj^erlinks of any HTML 

5 page that is associated with Use traosaction. By reraovjng the irausaction ID atajot^oas froju 
the hyperlinJ(s of the HTML page, subsequent browser requests that are issued in response to 
selection of a hyperlink from the HTML page will aot contain the globally unique transaction 
ID and, therefore, will not be rtustakenly associated with this multiple-request transaction. 
At step 768, the cartridge 230 uses the dispatcher poitvter to return the HTML page 

10 getKrated in response to peribnning the opemtion specified ir. the browser tequest to the 
dispatcher 214 and notifies cartridge execiition engine 228 tiiat execution of ihe Iransaction 
request is complete. 

At step 770, the carJiidge execution engine 22S sends a tnmsactiou control message to 
the transaction rnattager 606 requesting it to commit the transaction. At step 771, the 

15 transaction manager 606 sends a commit request to database servers 608 ai^d 61 2 to cause at! 
changes made in response to the various browser requests that bsionged to the ro«hip1c- 
request fransaction to be committed as an atomic unit of work. Tite comtsit request includes 
the globally unique transaction ID which allows the database servers 60S and 612 to identify 
the associated rnultipieHrequest transaction. 

20 At step 772, the cartridge execution engine 228 notifies the dispatcher 214 that the 

processing of the revised browser request is compile and signals the dispatcher 214 to cause 
the cookie information associated with the committed multiple-request transaction to be 
removed from the sending browser. By removing the trawsaction ID from the cookie 
information associated with the sending browser, subsequent browser requests will not contain 

25 the globally unique transaction ID and, therefore, will not be mistakenly associated with tiie 
committed multiple»jequest transaction. Control then returns to step 702 to intercept another 
revised browser message. 

At step 174, the cartridge execution engitje 228 determines wheUter the revised 
browser message is associated wiUt a rollback transaction \Mt In determining whether the 

30 revised browser message is associated with a rollback transaction URI, the cartridge execution 
engine 228 uses the cartridge name to identify thepreviotisly stored metadata tijat corresponds 
to the transaction type indicated in Uie revised browser message^ Using the previously stored 
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metadata, the cartridge exec«tion engine 228 determines if tbc revised bmwser message 
contains a rollback transaction URI, 

For example, it shall b« assumed that the revised browser message comained a 
cartridge name of STOREFRONT and a UIU of /storefront/ roHback^sessior*. Using the 
5 STOREFRONT cartridge naiue^ the cartridge execution engine 228 determines &at the 
revised browser message is associated witjj th« njetadata for transaction TX { . Usiog diis 
metadata, the cartridge execution engine 228 determines that the IXRI of /storefront/ 
ronback__«e$sion is associated with a roltback transaction. 

If the cartridge execution engme 228 dctermmcs that tije revised browser message is 
10 not associated wjth a rollbvKk trdosxictioii, t-icn contsot proceeds to step 804 

If the cartridge execution engine 228 tietcrminc; that the reviijed browser message js 
associated wtth a rollback ttan&acUon, then a step 7"o tRt tartnd^c execution engine 228 
detenniut's, whether the header section of t'le revised bro%\ sc nuissdjc cotitatns cookie 
mfonnaiion If cartndge execution cngjac 22S determines that the header section of the 
1 5 revised browser message contains cookie mformation, then at step 778 the cartridge execution 
engine 228 extracts the gJobaSiy unique tr^saction ID from the cookie infoimation. Control 
then proceeds to 782, 

If cartridge execution engine 228 detennines that the header section of the revised 
browser message does not contain cookie infomi^ion, then at step 780 the cartridge execation 
20 engine 228 extracts the giobaliy unique transaction H) from the annotated IJRl. 

At ste^ 782, the cartridge cxectttioa engine 228 incorporates a resume transaction 
identifier {tx„resitme) in a transaction ctmtrol message. The cartridge execution engine 228 
then sends the transaction control message to the transaction manager 606. 

At step 784, upon receiving the resume transaction identifier, the transaction manager 
25 606 s^ds a resume reqtiest to database stivers $08 and 612 to canse them to itesume 

execution of the transaetioft. The resume request includes the globally unique trattsaction ID 
which allows the database servos 608 and 612 to identify the multiple-request transaction that 
is associated with the current transaction request. 

At step 786, the cartridge execution engine 228 sends an opet^tion menage to 
30 cartridge 230 that is based oa the transaction information contait^cd in the revised browser 
message. The operation message also contains a dispatch^ pointer that idenliSes the 
dispatcher that sent the revised browser request (dispatcher 214) and allows the cartridge 230 
to write Infotmation back to the dispatcher. At step 788. upon receiving the operation 
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message* the eartndge 230 seads a message to the transaction manager 606 riegwesting hwidies 
for access to the databases that are ased m the specified tjT[>e of transaction. 

At step 790, tramaction maaager 606 returtjs handles to the appiopriate database 
servers to allow the cartridge 230 to proctsss the transaction request. For exampie, a$st«ntag 
5 database 61 0 is associated with the SEARS database a»d database 614 is associated with the 
BANK ! database, transaction manager 606 will return handles to database s<^er 608 and 612 
respectively. 

At st«^ 792, cartridge 230 uses the handles returned from transaction manager 606 to 
execute the transaction information associated with the operation message that was sent by the 

10 cartridge'execution engine 228, 

At step 794, the cartridge 230 determines whether the sending browser allows cookie 
information to be associated witii the browser. If the browser does not allow for cookie 
infonnatSon to be associated with the browser, at step 796, the cartridge 230 catises the 
globally unique tr;msaction ID to be removed from Ihc aiyiotated h>'periijiics of atiy HTML 

1 5 page to be returned to the ba->wser. By removing the transaction ID amwtations from the 
hyperlinks of the HTML page, subsequent browser requests will not contain the giobally 
unique transaction JB aiid, therefore, will not be mistakenly associated with this multiple- 
request tratisaction. 

At step 7&S, the cartridge 230 uses &e dispatcher pointer to return the HTML page that 
20 t$ associated with executing the traasaction back to the dispatcher 214 and notifies cartridge 
execution engine 228 that execution of the transaction request is complete. 

At step 800, the cartridge execntion engine 228 sends a transaction control message to 
the tmnsaotion manager 606 requesting it to rollback the transaction. At 801 , the 
transaction manager 606 sends a rollback request to djUabase servers 608 and 612 to cause ali 
25 changes made in response to the browser requests that belong to the mtJlHple-tequest 
traasaction to be mlted back as an atontic nnit of work. The roil back request includes the 
globally unique transaction ID which allows the database servers 608 and 612 to identify and 
roll back the correct multiple-request tt^action. 

At step 802, the cartridge execution engine 228 notifies the dispatcher 214 «iat the 
30 processing of the revised browser request is complete and signals the dispatcher 214 to cause 
the cookie information associated with the rolled back tnultiple*requ^ traasaction to be 
removed from the siding browser. By nsmoving the transaction ID from the cookie 
infonnation associated with the sending browser, subsequent kowser requests wiU not contain 
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the globally unique transaction E> and, thet«fore, will not be mistakenly associated with the 
rolled back mutople-wxiiiiest transaction. Contro! then tetoms to step 70a to tnterc«^t anotho- 
revised browser message. 

At step 804, the cartridge execation engine 228 determines whe&er the header section 
5 of the revised browser messai^ eontains cookie information. If cartridge execation engine 228 
determines that the header section of the revised browser message contains cookie 
infonnation, then at step 806 the cartridge exeoition engine 22B extracts the globally unique 
transaction ID &om the cookie inforrnatior;. Control Uiesj proceeds to SI 0. 

If cartridge execution engine 228 detemrmes that the header section of (he revised 

1 0 browser message does not contain cookie informatioia, ihen at step SOS the cartridge execution 
engine 228 extracts the gtobaliy unique transaction E> from the ataiotated URi. 

At step 810, the ciijtridge execution engine 228 packages a resume transaction 
identifier (tx„resame) in a fiinsaction control message. The cartridge exccutioa engine 228 
then sends the transaction control message to the transaction manager 606, 

15 At step 812, upon receiving the resume transaction identifier, the transaction manager 

606 sends a resume request to database servers 608 and 612 to cause them to resume 
execution of the transaction. The resume request includes the globally uni<3ue transaction ID 
which allows the database servers 608 and 612 to identiiy the mnltiple-reqttest transaction that 
is associated with the curreni transaction request. 

20 At st«p 814, the cartridge execation engine 228 sends an operation message to 

cartridge 230 that is based on the transaction infonnation contained in the revised browser 
message. The t^eration message also contains a dispatcher pointer Ujat identifies tite 
dispatcher that seat the revised browser request (dispatcher 214) and allows the cartridge 230 
to write information back to the dispatcher. At step 816, upon receiving the operation 

25 message, the cartridge 230 sends a message to the transaction manager 606 requesting handles 
for access to ttte dat^E*ases thsa are associated with the transaction. 

At step 81 8, transaction manager 606 returns handJes to the appropriate database 
servers to allow the cartridge 230 to process the transaction request For exatnpie, assuming 
database 610 is associated with the SEARS database and database 614 is associated with the 

30 BANKl database, transaction manager 606 will retam handles to database servers 608 and 
612 respectively. 
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At st^ 820, cartridge 230 uses the handles retunied from transaction manager m& to 
cacecyte the operation specified in the operation message that was sent t>y the cartridge 
execution engine 228, 

At step 822, the cajtridge 230 deterniiaes whether the sending browser allows cookie 
5 information to be associated with the browser. If the browser does not allow for cookie 
information to be a$sociat<sd wth the browser, at step 824, the cartridge 230 causes the 
hyperlijdcs of an HTML page generated in response to perfbnniog the operation to be 
amsotated to inclade the glohaUy unique transaction ID. By annotating the h>'per!inks of the 
HTML page, the URls in subse<^«erjt browser rei|ue.sts that are issued in response to selecting 
10 the links in the HTML page will contain the globally imkjue Jransaction ID. 

At step 826, the Cimridge 230 uses the dispatcher pointer to return fee HTML page 
thus generated back to the dispatcher 2 \ 4 and notifies cartridge €3te«^ition engine 228 that 
ekeeutton of the transaction request is complete. 

At step 828, the cartridge execution engine 228 sends a message to the transaction 
1 5 manager 606 requesting it to suspend the transaction. At step 830, the transaction manager 
606 sends a suspend request to database servers 608 and 612 to cause them to suspend 
execution of the transaction. The suspend rcijoest includes tbfs globaliy unique transaction ID 
which allows the database servers 608 and 612 to accurately identily the muitiple-rcijuest 
transaction to be suspended. Coa^oi then returns to step 702 to intercept another revised 
20 browsentjessage. 

TRANSACTION TIMEOUTS 
According to one embodinsent of &e invention, a timeout value is associated with each 
Si^action, Tike timeout value is used to identify multiple-mittest transactions ttiat have not 

25 been active for a specified time period. In one embodiment, each database server maintains a 
timeout value for thetnuHiple-request transacatajs that at« being serviced by the database 
server. Thus, whenever a multiple-request transaction begins to esxecute, the associated 
database server initialistes the timeout value for the particular transaction. Upon receiving a 
resume ttansactioa request that is associated with a globally unique transaction ID, Uie 

30 database server resets the tintjeout vahie for the maltiplerrequest tntnsaction that is associated 
wi«i the giobaity unique transactiion ID. If a multiple-itsquest transaction times mi, (he 
database server causes all changes made as part of the multiple-request transaction to he tolled 
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back as an atomic «nU of work. Once the multtple-resjuesf transaction is mlled back, a 
message j$ then sent to tiie associated browser to mdjcate the state of the tfansactioii, 
CONDUCTING TRANSACTIONS IN A STATELESS WEB ENVIRONMENT 

The present invention provides a practical and highly scaiabk mechanism for 
5 conducting multiple-request transactions in a stateless environtnent, such as the wd>. 

According to &e invention, a transaction manager k used to coordinate the overaH tiansaction 
process. Preferably, tlie transaction manager eoorditmte.^ the process in such a way that state 
information is maintained for a .transaction without requiring the transaction manager itself to 
persistently maintain the state infoimation, 

10 In a preferred embodiment, processing of a cisent request is perfomted as follows. The 

transaction manager receives a request from a client, and if tiie request is a transaction request, 
the rRanager initiates a transaction with a transaction processing mechanism, such as a 
datable management system (DBMS). Once the transaction is isitiated^ the manager 
preferabJy forwards the request to motixcr entity, such as an application, which actually 

15 processes the request. Afler the request is processed, control ss returned to the manager, and 
at that point, the manager assembles a set of state information associated with the transaction. 
This state information may include the identity of the client, the ID and status of the 
transaction, and what has already transpired in the transaction. Once assembled, the state 
information, along with the response to the client request, is sent back to ttie cliaat to be 

20 maintained by the client The state information may he sent to the client in the form of a 
"cookie" or it may be tnwrporated into a liRL diat is returned to the elitatt. While it is 
possible to do so, state infoimation is psreferably not persistently maintained by the manager or 
by the application that processed the request. 

When the client submits a second request relating to the same transaction, the client 

25 s^ds along the state information piwiously provided by the manager. Upon receiving the 
second request, the manager extracts ttie state information from the request, and uses it to 
resume Hie previously initiated transaction with the DBMS. Once the transaction is resumed, 
the manager sends the second request, including the state information, to another entity (the 
same or a different application) for processing. After the second request is pmcessed, the 

30 manager updates the state information associated with the transaction, and sends the updated 
state information, along with the reqfionse to the second request, to the client. The cU««t will 
send this updated state information in a future request to resume the transaction. This process 
repeats until the transaction is either corniaitted or roiled hack. 
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The present invention provides several siguifjcant advantages. Firet, note that the 
tran$act}on manager and the applications that process the requests tesiain statete. Tliat is, 
the transaction manager and the applicjUions are not required to maintain any of the state 
information for the transaction. All of that information is maintained by the client. This 
5 means that no overhead is incuired for storing the iafonnation. More importantly, tiie fact that 
the cUent maintains its own state infonnation means that aiiy request from the client can he 
- processed by any thread> process, or node. This stp^ificantly improves scalabiHty becaase it 
elirainMes the need to have a dedicated process or tiircad for each chent. 

Another point to note is feat even though the client is maintaining the state 
10 information, the client is not aware that it is maintaining tratisaction-specifsc state informatton. 
As discussed above, the state informatson is provided to the client by the transaction manager. 
The client simpiy send.s this information back to the transaction manager when it makes its 
next request. The client is not, nor does it need to be, aware that it is maintaining state 
information. Thi.s is a vet>' advantageous aspect of the present invention because it obviates 
1 5 the need to put any state management logic on the ciieivt. This in turn means that no changes 
or addition.^ need to be made to the client for the present invention to operate properly, 

Hence, tlje present invention provides a practical, scalable, md effective mechanism 
for conducting transactions in a stateless environment- These and other advantages of the 
invention will become apparent as the invention is described in forther detail. 

20 

INCORPORATION OF STATE INFOIU^ATION IN URLS 
The present inveotioa pmvides an effective and highly scalable mechanism for 
supporting mnUipJe-rcquest operations (including but not limited to transactions) in a stateless 
environment, sach as the web. According to the invention^ a server is preferably used to 

25 coordinate the overall processing of client requests. Preferaiily, the server perfotms this 
coordination function in such a way that: (1> state information associated with multiple- 
req««5St operations is maintained by the cHents making the requests; (2) the clients are 
unaware that they sffe maintaining operation-specific state infennation; and (3) the server 
itself is not required to persistently mainiwn the state information, ther€^>y remaining stateless. 

30 In a pref«gnred <mibodjment» processing of a client request is performed as follows. The 

server receives a request from a client, and if the request is for a multiple-request operation, 
the server initiates m operation. Once the operation is initiated, the server may either forward 
the request to anoth^ entity {such as an application) for jwocessing, or tiie sender may process 
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the request ttseif. After the request is processed, the server assembles a set of state 
mfonaation associated with the operatioii. This state infonnation my include iSte i<ieat% of 
the cKent, the ID and status of the operation, what has aiready transpired in the operation, and 
any other context itjfoimation associated with the operation. Ctoce assembled, the state 

5 information is i»coip<»ated into a XML. This UltJL, along with the response to the client 
request, is sent back to the client to be inainiaiiied by the cJi«(it This state mfomiation is 
preferably not persistently maintamed by the server. 

When the client submits a second request relating to the same operation, the client 
sends the URL that was previously provided by the ssr^^er which contains the state 

10 infonnatson. Upon i-ecciving the second request, the server extracts tlie state infomjalion from 
the URL, atid uses it to resume the previously initiated operation. With the benefit of this 
state infomiation, the server cat) resume llie operation at the exact point at which the previous 
re<|afist stopped. Once the operation is resumed, the server either processes the request, or 
forwards it to ariother caJtity for processing. After the secx>nd reqae.st is processed, the ser\'er 

} S updates the state information associated with the operation, and incorporates the updated state 
infonnation into ajiother URL. This URL, along vvith the response to the second request, is 
seat back to the chent to be maintained by the cHent, The client will send this URL in a future 
request to resmne the operationK This ptocm repeats until the operation is either completed 
or canceled. 

20 . The present invaation provides several sigjJtfjcjKRt advantages. F«st» note that the 
server remains stateless. That is, the server is not required to maintain any of the state 
infomiationforthetraajsaction, Atlofthattnfonnationistnaintasnedbytheclient. This 
means that no overhead is inounred for storing the infotmation. Mare importantly, the fact that 
the client maintains its own state information meatts that any request from die client can be 

25 processed by any thread, proeess, or node. This significaatly improves scalability heoausc it 
eliminates the need to have a dedicated process or thread for each client. 

Another point to note is that even thougfi the client is maintaining the state 
information, the client is not aware that it is maintainiiig operation-specific state informatitan. 
As discussed above, the state information is prqvided by the server to the client in the form of 

30 a URL. The cliem simply sends tMsUM.-whenev^ it requests service firomtijese Ute 
client treats this URL like any oihsr URL. The client is not, nor does it need to be, aware tisat 
this URL contains state information. This is a very advantageous aspect of the present 
invention because it obviates the need to put any state managcmeat lope m the client. This in 
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turn means that m changes or additions need to be made to the climt ibr the present inventjon 
to operate pr<^ly. 

Hence, the present invention provides a pflracticat, seaiabie. and effective mechanism 
for supporting multiple-reqnesl opta^tions in a stateless environment. These and other 
5 advantages of the invention will become apparent as the invoition is described in fiirther 
detail. 

In the foregoing specification, the invention has been described with reference to 
specific cwibodiments thereof. It wiU, however, be evident that various modifications and 
changes may be mads Oiereto without departing j&otn the broader ^irit and scope of the 
1 0 invention. The s|>ecification and dirawings are, accordingly, to be regarded in m illustrative 
rather than a reslxictive sense. 
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CLAIMS 

Wliat is ciaimed is: 

1 , A method performed by a transaction manager for eandactmg a transaction in a 
stateless enviroiunent, comprising the steps of: 

receiving a request sent by a client, said request including state infbnniuion associated 

with a previously initiated *ra«$action; 
extracting said state infonnatioa from said request; and 

using said state information to resume said transaction with ti«ftsactio» procmitig 
mechanism. 

2, The method of Claim 1 further comprising tho steps of: 

assembUng updated state information assocssacd with said transaction; and 
sending said updated state information to said client to be maintained by said client. 

3, Th€i method of CJaim 2 wherein said transaction manager is not repired to persistently 
maintain said updated state infoxmation, 

4, The method of Claim 3 wherein said client maintains said updated state iaformatioft 
without being aware that it is maintaining transaction-^ecific state information. 

5, The method of Claim 2 whaeia the step of sending said updated state information 
comprises tiie st^ of: 

incoipoiating said updated state information into a univmal resotiice locator (URX); 
and 

sending said URL to said ctient, said URL being used by said client in a fiitarc request. 

6, A method performed by a trxV.saction manager for conductiJJg a transaction in a 
stateless envirownein, comprising the steps of: 

reeeivtng a request sent by a client; 

generating traj^sactioa identification infonnation; 

using said Mentifioatwn information to initiate a transaction with a transaction 
processing mechanism; 
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assembiing state tnfomiatioa associated with said tramactiojsj aad 
sending said state information to said client to be maintained by said cUmt 

7, The method of Ciaim 6 wherein said transaction managtar is not reqajred to persisteatly 
maintain saJd state irrfbtmalion, 

8. The method of Ciaim 7 wherein said client maintains said state information without 
being aware that it is maintaining ttansactioa-^eciftc state informatioti. 

9. The method of Ciaim 6 wherein the step of sending said state infonnatiOB to said cK«!nt 
comprises the $t«p$ of: 

jncoiporating said state information into a universal resootce locator (URL); and 
sending said ORL to said client, said Uia being tised by said client in a future lequest. 

10, In a system comprising a client, a server for savicing requests fiom said client, and a 
traaisaction processing mechanism, a method perfonned by said server for conducting 
a transaction, comprising the steps of; 

receiving a request sent by said client, said ws^nest includittg state informatiani 

associated with a previoasly-aiitiated transaction; 
extracting said state information from said request; and 

using said state information to resume said transaction with said transaction piooe^rog 
mechanism; 

wherein said server is not raqmred to persistentiy maintain said sUte information, 
thereby rmaining transactionaUy stateless. 

1 L The method of Claim 10 wherein said slate information is maintained by said client, 
and vdieretn said client maintains said state mfomiation without being aware that it is 
maintaining transaotion-specifjc state ittformatioii- 

12, The method of Claim 10 further comprising the steps of: 

assembling updated state information associated with said trai^iaction; 
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incoipomtjRg said updated state informatioa into a usiversal resource Jocator (URL); 
and 

sending the URL to said client, said URl, being used by said climi in a future nequest 

O , A compyter-readabie medium bearing s equeaces of instractions perfonsed by a 
5 iransaclioiJ maiager for coftducting a transaction, in a stateless environment, the 

sequence of Instaictions including instructions for performing the steps of: 
receiving a request sent by a client, said request inejudjng state infon«ation associated 

with a previously initiated transaction; 
extraottng said state isfbrmation Irom said request; and 
1 0 using said state i nfonnation to resume said transaction, 

14, The computer-readable medium of Ciaim 1 3, wherein the computer-readable naedtum 
ifurther comprises instnictions for performing the steps of: 
assembling updated state information sissociated with said transaction; and 
seiiding s^d updated state information to said client to be maintained by said client 

15 15. The computer-readable medium of Claim 1 4, v^erein said transaction manager is not 
reqttiied to persistently mmntaitt said tipdated state information. 

1 6, The computer-Fsadabie medium of Claim 1 4, wherein the step of sending said updated 
state information comprises the step of: 

incorporating said tipdated state tnfetmation into a ai»tversai resource locator (URL); 
20 a«d 

sending said URL to said client, said URL hsmg used by said client in a future request 

17. A compuler-readabie medium bearing sequences of instructions for performed by a 
transaction manager for conducting a transaction in a stateless envitoament, the 
se(}uence of instructions incltiding instructions for performing the steps of: 

25 receiving a request sent by a client; 

geseratlng traasaction identification iitfoimation; 

using said identification infonnation to initiate a transaction witit a traasaction 

processing nwdjaiusm; 
assembling state information associated with said transaction; md 
30 sending said state information to said client for said state information to be maintained 

by said client. 
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Th& compuler-readabk medmm of Cia»m 17, wheresB said transactton manager is not 
required to persisitsBtiy maintain sasd stale juforraation. 

The compfter-Teadable mcdjum of Claim I?, wherein Oie step of sending said state 
infonnatton to said cliem comprises the steps of: 

incorpotatiag sad state information iato a uatvetsal resource locator (URL); and 
sending said URL to said client* said URL being used by said client in a future mjuesl. 

A computer-readable medium bearing sequences of instructions for a system 
comprising a client, a server for servicing requests from said client, and a transaction 
{HTDcessiitg mechanism said instruction being performed by said server to conduct a 
trzuisactioR, the se<|uence of instructions including instructions for per&nmng tiie 
steps: 

receiving a request sent by said client^ said request including state information 

associated with a previously-initiated transaction; 
extracting said state information from said request; and 

■using said state infonnation to resume said tratiisaction with said transaction processing 
mechanic; 

M?herein said server does not persistently maintain said state information, thereby 
remaining traaisactionaily stateless. 

The computer-readable medium of Claim 20, wherein the computer-readable medium 
farther comprises instructions for perfonning the steps of: 
assembling updated state infonnation associated with smd transaction; 
incorporating said updated state infocmatiim into a universal resource locator (URL); 
and 

sending the URL to said client, said URL being used by said client in a future request- 

A system for conducting a transaction in a stateless environment, the system. 

eom^siag: 

a memory; 

one or more processors coupled to the memory; mi 

a set of computer instructi(»is contained in the memory, the set of computer 

instructions including computer instructions which when executed by the one 

or more processors, cause the one or more processoi^ to perfonn tije steps of; 
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a transacti'oa maBager receivmg a request sent by a client, said request 
irtciudmg staie mfonuation associated with a previoiJsiy itiitiated 
tmmc^on; 

the transactioR manager extiactbg said state infonaation fmm $md request; md 
5 tile transaetiom maaager using said state informatioji to reswine said »a«sactioii. 

23. The sysicBi of Claim 22, wherein the transaction manager is fiirtibfiT cosligtifcd to 

jKirforTn the steps of: 

assembling updated state infonnation assctciated with said transaction; and 
sending said updated state iafomiation to said client to be maintained by said client. 

10 24. The ^steittofCJaita 23, wherem the tmtsaction manager is configuied so that 
lequired to persistently inaintaini said tipdated State infonnatioxt. 



25, A system for conducting a traasactioti in a stateless envitomneirt, the system 
comprising: 

a memory; 

15 orte or more processors coupled to the memory; and 

a set of caraputer instructions contained in the memory, the set of computer 

instructions i»clu<Kng computer instmctions which when executed by the one 
or mot« processors, cause the one or more pj5ocessors to perform the steps of; 
receiving a request sent by said client, said request tsicluding state information 
20 associated with a previousiy-mitiated transaction; 

extracting said state infonnatioii from said t equess; and 

using said state information to resume said traasaction with said tratisactson processing 
mechanism; 

wherein said server does not persistejitly maintain said state inlbiraation, thereby 
25 remaining transacttonally stateless. 

26. The system of Claim 25, wherein the system fiirther comprises instructions for 
performing the stei^ of: 

assembling updated state information associated wittt said tr^saction; 
incorporating said updated state information into a tmivemi resource locator (URL); 
30 and 

sending the URL to said client, said URL being used by said cHeM in a future request. 
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